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Vuoi sapere proprio tutto 
sui migliori videogiochi? 




LA GRANDE GUIDA A TUTTI I GIOCHI 


La prima vera grande guida indipendente 
a tutti i migliori giochi per computer, 
console, giochi da bar e altro ancora. 

In ogni numero trovi: 

• più di 30 giochi al microscopio 

• novità e anteprime 

• i game da bar più gettonati 

• recensioni dei giochi più famosi 

• Nintendomania. 
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La ripresa dei titolo dello scorso numero non è dovuta olfatto che sia diventato di successo, come è stato 
per Rocky, ma è semplicemente dovuta alla necessità di approfondire temi, diciamo, che sono cari alia 
testata. Fin dall'inizio abbiamo cercato di segnalare c/uei mali congeniti che affliggono il mondo 
dell'informatica consumer italiana. Non che /'informatica "personale", indicando con questo il mondo che 
gravita attorno ai personal computer usati in ufficio, non soffra degli stessi problemi, solo che c’è una 
maggior quantità di denaro e una ignoranza più diffusa. 

Dopo aver lanciato accuse a tutti, dai commercianti, ai produttori e ai centri di assistenza, nonché agli 
utenti che si tirano la zappa sui piedi, abbiamo ricevuto poche risposte: un centro di assistenza, alcune 
lettere e, indirettamente, da una ditta produttrice di software. 

Il centro di assistenza autorizzato da Commodore si chiama Computer Lab e si trova a Milano. Si è 
lamentato del fatto che non tutti i centri assistenza siano gestiti da persone improvvisate e con mezzi 
tecnici e scadenti. Siamo andati a trovarli e /’impressione che ne abbiamo ricavato è stata buona: sia il 
cliente che il computer vengono trattati con cura e professionalità. Sicuramente è un centro di assistenza 
che si distacca dalla media. 

La ditta si chiama Cloanto, è di Udine e ha prodotto un word processor di nome CI-TEXT. Il software è di 
ottimo livello e confrontabile con prodotti d’oltre oceano: non ne esiste comunque uno che gli sia 
superiore. È pensato per il mercato europeo e la versione italiana sarà imbattibile per diverso tempo. Il 
prezzo è di 69.000 lire, compresa la spedizione espressa a casa se non lo si riesce a trovare in un negozio, 
con un esauriente manuale in dotazione. Non sarebbe un furto, copiarlo? 

Le lettere parlano invece genericamente di varie disavventure e chiedono quali possano essere i rimedi a 
una situazione del genere. Come credo sia stato chiaro dall'editoriale del numero precedente, ritengo che 
la situazione da terzo mondo in cui si trova l'informatica italiana sia dovuta al radicato "malcostume" di 
copiare il softw are e, addirittura di rivenderlo, causando un doppio danno al produttore! Per rendesi 
conto di quanto sia estesa questa pratica è sufficiente riferirsi a una vicenda della scorsa primavera 
quando venne accertato che diverse grosse aziende italiane, taciamo il nome per stendere un velo pietoso, 
utilizzano in massima parte software copiato. 

Gli italiani, si sa, sono il popolo che "fatta la legge, trovano l’inganno"; figuriamoci se la legge non esiste 
nemmeno. Proprio la legge di tutela del software è il punto centrale del problema: senza quella non è 
possibile rimediare alla situazione se non con azioni sporadiche di qualche entusiasta (leggi Cloanto, 
Computer Lab e chi altro). Siamo rimasti l'unico paese industrializzato senza uno straccio di legge e 
peggio di noi si sta solo in America latina. Nel panorama del!'editoria tecnica italiana è un fiorire di 
editorialisti che invocano leggi adeguate per il proprio settore. L'esempio più lampante è quello di una 
rivista di informatica ben nota dove il proprio direttore da anni (due ?) invoca, coprendo di ridicolo a più 
riprese la SIP e i ministeri competenti, una legge e un po' di sensibilità riguardo l’utilizzo dei modem e 
della telematica personale. Spero, sebbene sia convinto del contrario, di non dover scrivere, così come 
l'illustre collega, ancora due anni di editoriali prima che venga approvata una legge minima. 

A chi poi si fosse scandalizzato per la parola "mafia" presente nell' editoriale del numero scorso, e ne 
avrebbe ben donde, mi permetta di ricordagli che Transactor è una rivista un po' "scomoda" per il 
movimento che ruota attorno ad Amiga e che siamo costretti a muoverci tra gelosie, incomprensioni e 
bastoni tra le ruote. Se poi si fosse ulteriormente dubbiosi basta contare le pagine di pubblicità presenti in 
questo numero o in quelli scorsi. 


TU 




Marco Ottolini 
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Lettere e Bit 


Gentile Redazione, sono un vostro appassionato lettore posses¬ 
sore di un Amiga 1000. Tralasciando i mentalissimi compli¬ 
menti per non farla troppo lunga, passerei subito alla 
questione: leggendo la vostra rubrica "LETTERE..." del n. 3 di 
Transactor ho notato un problema esposto dal Sig. Massimo 
Rainato nella sua lettera. Il problema riguarda la mancanza di 
certa documentazione sulle LIBRARY di Amiga; mi spiego 
meglio: il Sig. Rainato (come penso molti altri possessori /pro¬ 
grammatori di Amiga) non ha trovato alcun problema nel repe¬ 
rire la documentazione riguardante le famose librerie in 
questione, il loro significato tecnico e la loro utilità, i problemi 
sorgono però quando le si devono utilizzare, come fare? 
Sfruttando la mia poca esperienza e alcune giornate di pioggia 
sono riuscito a scoprire (ma forse non è questa la parola giu¬ 
sta...) le famose routine disponibili in ogni libreria. La cosa, 
che può sembrare abbastanza ardua, si rivela di una semplicità 
che fa paura. Le librerie di cui parlo sono quelle disponibili da 
BASIC, visto che i miei "esperimenti" sono stati tutti eseguiti 
in questo linguaggio, ma in seguito darò alcune buone notizie 
anche per quello che riguarda il C. 

Passiamo dunque ai fatti, tutti noi abbiamo nel nostro dischetto 
EXTRAS il famoso AmigaBASIC, in questo dischetto è pre¬ 
sente anche una directory molto importante: FDx.x (la x.x sta a 
indicare la versione del nostro EXTRAS). Se visualizziamo il 
contenuto di questa directory ci accorgiamo che sono presenti 
dei file che terminano tutti in "_lib.fd”, sono proprio queste le 
famose librerie che possono essere utilizzate dal BASIC, o me¬ 
glio, sono queste trasformate in file ".bmap" (per fare ciò, tutti 
sapranno che bisogna utilizzare l’utility presente nel dischetto 
Extras, nella directory BasicDemos di nome "ConvertFD") che 
dovranno essere presenti nello stesso dischetto in cui risiede 

T AmigaBASIC. 

Dopo questa parentesi non del tutto necessaria vorrei tornare ai 
file ",fd" di prima e alla loro importanza: è proprio in questi 
che sono presenti le famose routine disponibili in BASIC; se 
noi facciamo un veloce dump di queste (basta il comando Ty- 
pe) ci accorgeremo che appariranno come un intero file ASCII 
in cui sono contenute ordinatamente le routine disponibili ed i 
parametri necessari. 

Sembra impossibile, vero ?!? 

Ma diamo un’occhiata più da vicino a questi file: le prime due 
righe sono riservate al sistema: la prima dà il nome della libre¬ 
ria, la seconda non ho ancora capito a cosa serva. Dopo ciò se¬ 
guirà una favolosa lista di routine disponibili (che saranno la 
gioia di tutti i possessori di Amiga) seguita ognuna dai parame¬ 
tri necessari a dai registri che utilizzerà (opzionali quando si 
utilizza la routine); alla fine del file ci sarà quasi sempre la pa¬ 
rola "##end". C’è da notare che alcune routine non saranno di¬ 
sponibili: sono quelle precedute da "##private". 

Qui sopra ho descritto come conoscere le potenze utilizzabili, 
ma non posso prolungarmi nel descrivere come utilizzarle per¬ 
ché la carta è tiranna, quindi mi limiterò solo ad accennare alle 
librerie con il C. Queste sono molto più complesse che nel BA- 

SIC (cosa abbastanza immaginabile) e cercherò di sintetizzare 
al massimo: ogni compilatore C (io uso il Lattice) è dotato di 
una directory "include", qui sono presenti le famose ed estese 
librerie disponibili; facendo il dump di ognuna di queste si pos¬ 
sono scoprire le varie Structure utilizzabili in un programma C; 
certo, prima occorre aprire la libreria con il comando "Include 
<nomelibreria>. e per quanto riguarda il resto vi rimando alla 
pratica. 

10 non me ne intendo molto di C, ma ho provato con successo 
quello che ho appena asserito. 

Per concludere vorrei porre i miei cordiali saluti al Sig.Rainato 
a cui consiglio di fare delle stampe dei file .fd per averli sem¬ 
pre a disposizione, e vorrei porre i miei saluti alla Redazione di 
Transactor, una grandissima rivista che spero in seguito mi¬ 
gliori la sua puntualità. 

Massimo Marcelli, Corciano 

Lo spirito d'avventura è sicuramente da lodare quando l'obiet¬ 
tivo delle ricerche è avere una maggior padronanza di Amiga. 
Purtroppo non è stato sufficiente ne a te, caro Massimo, ne ad 
altri che hanno solo fatto un po' di confusione pur essendo vi¬ 
cini alla soluzione dell' arcano. In realtà i file che hai esamina¬ 
to non sono le librerie, che tanti sonni tolgono ai 
programmatori, ma il mezzo per arrivare a usare le librerie. 

Le librerie sono delle collezioni di routine che si trovano diret¬ 
tamente in ROM (nel Kickstart), oppure sul dischetto del Wor- 
kbench nella directory libs (LIBS: sotto AmigaDOS). 1 
linguaggi di programmazione, siano essi il C. l’Assembler o il 
BASIC, non "sanno" come usare le librerie, finché non gli si 
forniscono le informazioni necessarie. I file fd, per esempio, 
contengono i nomi delle routine contenute nelle diverse libre¬ 
rie e l’elenco dei registri nei quali devono essere posti i para¬ 
metri. L’utility ConvertFD provvede poi, per mezzo di queste 
informazioni, a generare i file .bmap corretti, usati infine dal- 
l’AmigaBASIC per richiamare le routine delle librarie. 

11 C, per farla semplice, funziona in maniera simile, solo che 
tali informazioni si trovano nei file .lib contenuti, generalmen¬ 
te, in una directory "lib" (il nome avrebbe dovuto suggerire 
qualcosa al nostro "esploratore"). Oltre a permettere l’accesso 
alle routine di sistema i file .lib contengono, in realtà è questa 
la loro funzione, delle routine fornite a corredo del compilato¬ 
re quali printf, scanf, ecc. 

! file ,h, detti include in gergo, del C contengono invece una 
serie di istruzioni C valide che, per mezzo della direttiva in¬ 
clude <nome file> vengono inglobate all'interno di un pro¬ 
gramma C. Al loro interno si trovano solitamente dichiarazioni 
di costanti (Mefine) e definizioni di tipi di variabili che posso¬ 
no essere utilizzate in diversi programmi. 

Per quanto riguarda /’Assembler riferitivi agli articoli di Jim 
Butterfield sull argomento che, a partire da questo numero, 
saranno pubblicati su Transactor. 
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SoftMail 


SOFT Vendita per corrispondenza di programmi originali ed accessori per computers. 

MAIL VIA NAPOLEONA 16-22100 COMO TEL (031) 30.01.74 

——— ® SoftMail d un marchio registrato da Lago snc 


SOFT 

MAIL 


Presentiamo in questa 
pagina alcune tra le ultime 
novità disponibili dal ca¬ 
talogo SoftMail. Ecco 
alcune informazioni utili 
per utilizzare il servizio 
SoftMail: è possibile effet¬ 
tuare ordini telefonica¬ 
mente SOLO se è già stata 
effettuata una spedizione a 
proprio nome ed è stata 
regolarmente ritirata. Dal 
secondo in poi accettiamo 
ordini telefonici . Chi desi¬ 
dera notizie sulla disponibi¬ 
lità ed i prezzi dei prodotti 
che non compaiono in 
questa lista può chiamare lo 
(031)30.01.74 dalle 14:30 
alle 1&00. SoftMail può 
organizzare la conseg na 
anche tramite _ corriere : 

interpellateci per maggiori 
informazioni. Oltre alle 
ultime novità qui esposte, 
SoftMail offre Finterò cat¬ 
alogo delle seguenti case: 
Aegis, Cinemaware, EA, 
Microprose, Rainbird, SSI, 
SSG, Sublogic. 



ACCESSORI 


Comic setter 

139.000 

Rocket Ranger 

59.000 

Stunt bike simulator 

5000 



Comic setter art disks 

telef. 

Roger Rabbit 

89.000 

Ttger road 

15000 

Copritastiera A 500 

25.000 

Corruption 

49.000 

SEUCK 

telef. 

Total edipse (Hai.) 

15000 

Final caitdrige HI 

110000 

Cosmic pirates 

telef. 

Sex vixens in space 

55000 

4 soccer simulator 

18000 

Flicker master 

29.000 

Crazy cars 

29.000 

Sculpt/Animate 40 

telef. 



Joy. Slik stick 

16.500 

Def con 5 

59.000 

Sentinel 

49.000 

COMMODORE 64 DISCO 

Joy. SpeedKìng 

29.000 

Defender of thè crown 

59.000 

Sinbad 

59.000 



Joy. SpeedKing Auto!. 

33.000 

Deluxe prirrt II 

99.000 

Skyfox II 

59.000 

ADD: Heroes of thè lance telef. 

Joy. Tac 2 

29.000 

DigiP aint 

99.000 

Starfleet 

59.000 

ADO: Pool of radiance 

59.000 

Joy. Tac 5 

39.000 

DigiView GOLD 

telef. 

Starglider II 

49.000 

American dvil war III 

49.000 

MouseMai tappetino 

22.500 

Diredor 

99.000 

Superman 

39.000 

Barbarian II 

25.000 

Coprimouse 

20.000 

Disk drive esterno 

299.000 

Sword of sodan 

69.000 

Deathlord 

35000 

P ort amouse 

12.500 

Dos2Dos 

75000 

The bard's tale II 

49.000 

Driller 

29.000 

Portadischi 3” (30) 

34.000 

Dragon's lair 


The worksl 

249.000 

Echeton (con LipStick) 

59.000 

Portadischi 5” (40) 

37.000 

(1 MByte. 6 disks) 

75000 

Three Stooges 

59.000 

Eternai dagger 

35000 

SlimUne (tastiera 64) 

49.000 

DriHer TUTTO italiano 

59.000 

Tracker 

49.000 

Fast break 

29.000 

Voice messenger C64 

60.000 

Dungeon master (1 MB) 59.000 

TV Sports: Football 

59.000 

Fish 

29.000 



Elite 

45000 


Ultima IV 

49.000 

Game over l+ll 

25000 

UBRI/HINTS & TIPS 

Empire 

49.000 

Universal miNtary sim. 

45000 

GeoPublisher 

100.000 



FI 6 Falcon 

59.000 


Data disks 1 e 2 

telef. 

Grand Prix Circuit 

telef. 

Alternate city due 


Fantavision 

125000 

Vidory road 

39.000 

Gulf strike 

49.000 

specificare 8/16 bit 

1&000 

Fire & forget 

39.000 

Videoscape 30 20 

250.000 

Home video producer 

69.000 

Bard's tale 1 due 

22.500 

Fish 

45.000 


Designs disks 

telef. 

Italy 90 soccer 

25000 

Bard's tale II due 

25000 

Flight simulator H 

99.000 

VIP professional 

199.000 

LED storm 

15000 

Bard's tale HI due 

25000 

Scenery disks 

telef. 

Virus 

29.000 

Mars saga 

35000 

Black cauldron due 

15000 

Galileo 20 

99.000 

Virus infedion protedion89.000 

McArhtu's war 

49.000 

Deathlord due 

telef. 

Garfield 

49.000 

WB Extras 

69.000 

MicroSoccer 

telef. 

Dungeon master due 

25000 

Gauntlet H 

25000 

Whiriigig 

39.000 

Neuroman cer 

39.000 

Elite due 

iaooo 

Grabbit 

49.000 

WìHow 

59.000 

One on one II 

29.000 

Graphic adv, creator hint 7.500 

FMIfìre attack 

39.000 

World CI. Leaderboard 

25000 

Powerplay hockey 

29.000 

Mars saga due 

telef. 

Intemationai soccer 

39.000 

Zak McKracken 

59.000 

Red storm rising 

49.000 

Might & Magic due 

25000 

Italy 90 soccer 

39.000 

Zing keys 

25000 

Rocket Ranger 

telef. 

Pool of radiance de 

20000 

Incr.s.sphere 

49.000 

Zoetrope 

199.000 

Shoofem up constr. kit 

35.000 

Quest fot dues 

39.000 

Jet & Japan bundle 

115000 

Zoom 

45000 

Stealth mission 

75000 

Sentinel world due 

25000 

Joan of Are 

25000 

3 Demon 

145000 

T.K.O. 

29.000 

Starflight due 

25000 

King of Chicago 

49.000 




The bard’s tale NI 

35000 

Ultima V due 

22500 

LED storm 

25000 


COMMODORE 64 CASS. 

Total edipse (ita!.) 

20.000 

Wasteland due 

15500 

Legend of thè sword 

45000 




Ultima V 

49.000 



Life cydes vol.1 

39.000 

After bumer 

18.000 

Wasteland 

39.000 

AMIGA 


LjghtlCameralActionl 

99.000 

Barbarian H 

18000 

Wec Les Mans 

21.000 



Lords of Ihe Rising Sun telef. 

Batman 

18000 

Who framed Roger Rabbit telef. 

Herees lanca hints disk telef. 

Maior motion 

39.000 

Dragon ninja 

15000 

Zak Me Kracken 

39.000 

Bard’s tale hints disk 

telef. 

Maxiplan plus 

299.000 

Exploding fist+ 

15000 

4 soccer simulator 

25000 

Aegis draw 2000 

telef. 

Monaco 

39.000 

G.l.hero 

15000 



Aegis images 

69.000 

Mickey Mouse 

25000 

Italy 90 soccer 

18000 

COMMODORE 128 DISCO 

Aegis impad 

125000 

Modeler 3D 

129.000 

Last Ninja H 

25000 

(128K. 80 COL) 

Aegis sonix 

110.000 

Murder on Atlantic 

59.000 

MidoSoccer 

telef. 



Aegis videotitiler 1.1 

185000 

Nigel Mansell grand prix 49.000 

Robocop 

18000 

“C” Language 

99.000 

Alternate reafity: thè dty 69.000 

Obliterator 

45000 

R-type 

18000 

Basic 80 

75000 

Animahon multiplane 

125000 

Offshore warrior 

39000 

Serve & volley 

22000 

GEOS128 

telef. 

Armageddon man 

49.000 

Outrun 

25000 

Shoofem up constr kit 

25000 

Mach 128 

125000 


rs nnn 

P o w 

so nnn 






Audiomaster II 

telef. 

PacMania 

25000 


OFFERTE SPECIALI 


Baal 

29.000 

Phantom fightor 

45000 


(FINO AD ESAURIMENTO) 


Barbarian II 

telef. 

Pioneer piague 

59.000 


FIRBBIRD SPECIAL 

Vilort A lolt 

Batman 

29.000 

President is missing 

49.000 


AMIGA Bmbblc Bobbl«+Wlurligig+ 


Banlechess 

49.000 

ProSound designer 

79.000 


Enlitktcnmcat 

107.000 75.000 

Black cauldron 

9.000 

ProSound w/hardware 

199.000 


C64 citi. Savage+Iiteisity+Seitiiel 41000 33.000 

Bhtzkneg at Ardennes 

59.000 

Prowrite 20 

179.000 


C64di»co Savage + Inteniity+Sentinel 65.000 39.000 

California games 

25000 

Publisher plus 

125000 


AEGIS BNTERTAINMBNT 



Carrier command 

49.000 

Re adì for thè stars 

59.000 


AMIGA Arazok’i Tomb+Port» of Cali 120.000 89.000 

Celi animator 

telef. 

Rebel... Chickamauga 

telef. 


DBFBNDBR OF THE CROWN C64: «ai». 12.000 diico 15.000 

Chrono quest 

85000 

Return to Genesis 

39.000 
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Guida per gli utenti della BridgeBoard 


(o di un Amiga 1000 col SideCar) 


di Dan Schein 


Dan Schein ha fatto parte del Commodore Amiga Technical 
Support e ora lavora nel dipartimento di informatica di un 
ospedale della Pennsylvania. I suoi articoli tecnici relativi ad 
Amiga sono già apparsi su diverse pubblicazioni. 

Se gli si aggiunge una BridgeBoard, Amiga 2000 diventa un 
computer con due diverse personalità. Una tale combinazione 
rende la macchina differente da tutte quelle apparse in prece¬ 
denza? Per la verità, direi proprio di sì. Prima di addentrarci 
nella sostanza di questo articolo vorrei fare una precisazione: 
un Amiga 2000 con BridgeBoard è equivalente da un punto di 
vista funzionale a un Amiga 1000 con SideCar, quindi nel se¬ 
guito quando mi riferirò a un Amiga 2000 con BridgeBoard, le 
affermazioni varranno nella stessa identica maniera anche per 
un 1000 col SideCar. Se, poi, possedete proprio un 1000 col 
SideCar e vi accorgete che vi manca qualcuna delle utility e 
dei programmi di cui parlerò in questo articolo, vi suggerirei di 
andare dal vostro negoziante per acquistare una copia dell'ulti¬ 
ma versione del software della BridgeBoard. Da quando è stato 
prodotto il SideCar, infatti, vi sono state varie aggiunte di op¬ 
zioni e di utility, per non parlare poi delle diverse release del 
software del SideCar stesso; la cosa più importante, però, è che 
l'ultima versione del software della BridgeBoard funziona per¬ 
fettamente anche col SideCar ed è quindi quella da preferirsi. 

Il resto di questo articolo si fonda su due ipotesi di base. La 
prima è che abbiate seguito fedelmente le istruzioni di installa¬ 
zione presenti nel vostro manuale della BridgeBoard e che la 
BridgeBoard stessa sia stata provata e funzioni perfettamente. 
La seconda è che abbiate una sufficiente conoscenza sia di 
MS-DOS sia di AmigaDOS. Troverete utile avere a portata di 
mano il manuale della BridgeBoard 2088, il manuale del siste¬ 
ma operativo 3.2, il vostro manuale di Amiga, un disco da 3.5" 
vuoto e alcune ore di tempo libero per fare un po' di prove. 

La potenza che scaturisce dall’unione dei due sistemi operativi 
genera inevitabilmente alcuni problemi e alcune domande. Il 
fine di questo articolo è di chiarire quegli aspetti che risultano 
generalmente poco compresi e confusi. Tra le altre cose vedre¬ 
mo infatti come trasferire i file da MS-DOS ad AmigaDOS e 
viceversa, come approntare un hard disk con la Janus e come 
far formattare un disco MS-DOS da 720K all 'A 1010 (il drive 
da 3.5"). 


720K sul 3.5" 

Incominciamo dalla fine: ottenere 720K sul 1010. Quando con¬ 
nettete il 1010 alla BridgeBoard, questo, per default, formatta i 
dischi a 360K. Perché ci interessa tanto formattare a 720K? In 
primo luogo, questo è standard tanto quanto 360K sui dischi da 
5.25" sotto MS-DOS. La maggior parte dei portatili MS-DOS 
usa questo formato e i nuovi modelli IBM sono dotati di drive 
in grado di leggere e scrivere in questo formato; noi certamente 
non vogliamo essere da meno. Se poi tutti questi discorsi di 
compatibilità non vi interessano, basta che osserviate che 720 è 
il doppio di 360 e questo dovrebbe proprio convincervi. 

Bando alle chiacchiere e iniziamo a vedere che cosa bisogna 
fare per raddoppiare la capacità dei nostri dischi e diventare 
compatibili. Tutto ciò che dobbiamo fare è aggiungere una li¬ 
nea al file CONFIG.SYS. Il file CONFIG.SYS deve essere 
contenuto nella directory principale del disco che usate per fare 
il boot della BridgeBoard. Questo significa il disco di boot in 
MS-DOS e non il disco che usate per far partire il software che 
gestisce la finestra PC. Se sul vostro disco di boot MS-DOS 
non c’è già il file CONFIG.SYS, potete crearlo voi con l’editor 
di linea "edlin", che vi è stato fornito con la BridgeBoard. Po¬ 
tete usare "edlin", poi, anche se CONFIG.SYS esiste già e se, 
quindi, dovete solo aggiungere una nuova linea. Le istruzioni 
d’uso di "edlin" sono riportate nel Capitolo 6, seconda parte, 
del manuale del sistema operativo. Ecco la linea che dobbiamo 
aggiungere: 

driveparm=/D: 01 /F: 2 /H:2 /S:9 /T:80 

Gli spazi fra i diversi termini sono necessari; è fondamentale 
che mettiate esattamente questa linea così come è riportata qui. 
Il significato di questa linea e dei vari parametri è spiegato nel¬ 
l’Appendice B del manuale MS-DOS 3.2. Ora dobbiamo ren¬ 
dere attivo questo nuovo file CONFIG.SYS. A questo scopo 
dobbiamo operare il cosiddetto warmstart della BridgeBoard, 
cioè dobbiamo farla ripartire. Per fare il reset della sola Bridge¬ 
Board, clickate con il mouse dentro la finestra PC per renderla 
attiva e quindi premete ALT, CTRL e DEL (il punto nel tastie- 
rino numerico). A questo punto il vostro sistema vedrà il drive 
B come drive da 3.5" a 720K. Per verificare che tutto sia anda¬ 
to come previsto, basta semplicemente formattare un disco nel 
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drive "B". Al termine di tale operazione dovrebbe apparirvi 
questa scritta sullo schermo: 

730112 Bytes total disk space 
730112 Bytes available on disk 

Se così non fosse, ricontrollate il file CONFIG.SYS. 

Nota: questo trucco funziona anche se avete due drive da 5.25" 
(A 1020) sulla BridgeBoard; il problema è però che i dischi da 
5.25" formattati a 720K non possono essere letti dalla maggio¬ 
ranza degli altri utenti MS-DOS. 

Drive virtuali 

Il secondo argomento di cui ci occuperemo è costituito dai dri¬ 
ve virtuali. I drive virtuali sono trattati nel manuale della Brid¬ 
geBoard, ma richiedono comunque qualche chiarimento e 
qualche ulteriore spiegazione. Io vi fornirò un esempio di come 
approntare un drive virtuale, ma è lo stesso utile che troviate il 
tempo di leggere l'Appendice C del manuale della BridgeBo¬ 
ard, se non lo avete già fatto. Per usare i drive virtuali bisogna 
compiere tre operazioni. Il primo passo consiste nell'aggiunge- 
re la seguente linea al file CONFIG.SYS: 

device=jdisk.sys 

Una volta che avete salvato il file con questa modifica, potete 
resettare la BridgeBoard e passare alla seconda fase. Bisogna 
notare che mentre la prima operazione viene eseguita una volta 
per tutte, le due successive devono essere compiute ogni qual 
volta si intenda usare un drive virtuale. 

Il secondo passo consiste nel lanciare il programma "PCdisk", 
che si trova nel drawer PC nello schermo del Workbench di 
Amiga. A questo punto abbiamo creato un canale di comunica¬ 
zione tra MS-DOS e AmigaDOS. In questo esempio, useremo 
il disco RAM di AmigaDOS per ospitare il drive virtuale, ma 
potremmo allo stesso modo usare un qualsiasi altro drive. 

Come terza operazione, creiamo il drive virtuale. Battete nello 
schermo MS- DOS il comando seguente: 

jlink d: ram:ms-dos /c:160 

e premete Return. Come risultato, sullo schermo dovrebbe ap¬ 
parire: 

VDrive Status Linked to 


c : 

d: R/W ms-dos 

e : 
f : 

In questa maniera abbiamo creato un file chiamato "ms-dos" 
nel RAM disk di Amiga. Questo fde è collegato alla parte MS- 
DOS tramite il drive virtuale D. La sua presenza nel RAM disk 
di Amiga può essere verificata con la richiesta di una directory 


di RAM: (ovviamente da AmigaDOS); è importante precisare 
che questo file non può essere letto, copiato o cancellato da 
AmigaDOS fino a quando non viene chiuso (e vedremo tra po¬ 
co come farlo). Ad ogni modo, ora possiamo accedere al drive 
D come a un qualsiasi altro drive MS-DOS. 

Per provarlo, potete ad esempio chiederne la directory, copiar¬ 
vi il file CONFIG.SYS e leggerlo con il comando TYPE, can¬ 
cellarlo e chiedere un’altra volta la directory. Se non sapete 
come chiedere la directory, o come copiare un file, è opportuno 
che leggiate il manuale MS-DOS 3.2. 

Ora che disponiamo di un drive virtuale e sappiamo usarlo, 
spiegherò il significato dei parametri specificati col comando 
jlink. La "d:" indica che intendiamo chiamare il drive virtuale 
con il nome D. "ram:ms-dos" specifica che vogliamo che il dri¬ 
ve virtuale sia contenuto nel file chiamato "ms-dos" nel device 
RAM: di Amiga. L’opzione "/c:160" serve per limitare la lun¬ 
ghezza massima di tale file a 160K. Se non usiamo l’opzione 
"/c" e il file specificato non esiste già, il comando jlink non ha 
alcun effetto e viene restituito un messaggio di errore. Fio usato 
di proposito il numero 160 perché questa è la dimensione mini¬ 
ma che possa essere specificata per un drive virtuale (pensava¬ 
te che me lo fossi inventato, vero?). Se usate un numero 
minore di 160, la dimensione del file è posta automaticamente 
a 160K. In effetti, 160K non è la vera e propria dimensione del 
file, ma è la massima dimensione che può raggiungere. A giu¬ 
dicare dall'espressione dei volti, direi che è meglio che spieghi 
più chiaramente questo punto... 

Un drive virtuale funziona sostanzialmente come il RAM disk 
di Amiga nel senso che non occupa mai più spazio di quello 
che effettivamente gli serve (a meno che non si superi la di¬ 
mensione specificata nel comando jlink). Questo sta a signifi¬ 
care che il drive virtuale si espande solo quando vi salviamo 
dei file; a differenza, però, del RAM disk di Amiga, quando 
cancelliamo i file, il drive non si restringe, ma continua ad oc¬ 
cupare lo stesso spazio. Un drive virtuale si espande solamente 
e non si restringe mai. 

E ora opportuno parlare di due aspetti importanti: come scon¬ 
nettere e riconnettere un drive virtuale. Un drive virtuale do¬ 
vrebbe sempre essere scollegato al termine del suo uso e prima 
di spegnere la macchina. Se spegnete tutto senza aver scollega¬ 
to un drive virtuale, il file che ospitava il drive virtuale potreb¬ 
be risultare danneggiato e potreste incontrare dei problemi nel 
riconnettervi a tale file la volta seguente. Vediamo come scol¬ 
legare un drive virtuale. Battete la linea seguente: 

jlink d: /u 

e premete Return. Sul display vi dovrebbe apparire: 

VDrive Status Linked to 
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Questo indica che il nostro drive è stato scollegato e che al mo¬ 
mento non ci sono altri drive collegati. 

ne o alla riconnessione, fa in modo che il drive virtuale sia di 
sola lettura. Tutti i tentativi scrittura su questo drive falliranno 
e saranno accompagnati da un messaggio di avvertimento. 

Nota: Vorrei spendere un parola per avvertirvi della pericolo¬ 
sità di collegarsi automaticamente a un drive virtuale durante 
lo start-up (cioè mettendo un apposito comando nel file AU¬ 
TOEXEC.BAT). La BridgeBoard inizia la sua attività (a patto 
che trovi un disco di boot nel drive A) quando viene eseguito il 
comando "BindDrivers" di Amiga, indipendentemente dal fatto 
che abbiate aperto la finestra PC o meno. Questo significa che 
se collegate il drive virtuale automaticamente all’accensione e 
poi spegnete senza aver aperto la finestra PC e scollegato il dri¬ 
ve virtuale, finirete molto probabilmente col danneggiare il file 
che ospita il drive virtuale. Ci sono tre modi per impedire il ve¬ 
rificarsi di questo incidente. Il primo è di non usare il comando 
jlink nel file batch di start-up. Il secondo consiste nell’aprire 
sempre e comunque una finestra PC per scollegarsi prima di 
spegnere, il che è più facile da dire che da ricordare. Il terzo, 
che personalmente preferisco, è di inserire il comando "date" 
(o eventualmente "Time") nel file AUTOEXEC.BAT prima 
del comando jlink. Questo fa sì che se non aprite una finestra 
PC e non battete la data, non c’è alcun pericolo di perdere il 
contenuto del drive virtuale semplicemente perché il comando 
jlink non viene eseguito. Devo poi farvi notare che tutta questa 
discussione sul collegamento automatico del drive virtuale si 
basa sull'ipotesi che voi abbiate già lanciato il programma 
PCdisk manualmente o come parte della "startup-sequence". 

Congratulazioni! Siete sopravvissuti al corso introduttivo sui 
drive virtuali. Passiamo allora senza indugi al prossimo argo¬ 
mento. 

I drive Janus 

Un drive Janus è in realtà una partizione AmigaDOS che risie¬ 
de su un hard disk MS-DOS e a cui AmigaDOS accede come a 
un qualunque device. Grazie al fatto che MS-DOS permette 
che su un disco siano presenti diverse partizioni e grazie ad al¬ 
cune utility messe a disposizione dalla Commodore, possiamo 
trasformare una di queste partizioni in un drive Janus. 

A causa del numero enorme di differenti tipi di drive e control¬ 
ler di hard disk, non mi sembra opportuno che spieghi come in¬ 
stallare un hard disk. Nel nostro caso ci riferiremo a un hard 
disk da 20M partizionato in parti di uguale dimensione; in ge¬ 
nerale. potrà rendersi necessario fare alcuni specifici aggiusta¬ 
menti delle dimensioni delle partizioni. 

La BridgeBoard, come qualsiasi altro computer che usi MS- 
DOS come sistema operativo, richiede che, prima di formattare 
un hard disk, venga lanciato il programma "Fdisk", che potete 
trovare nel disco di sistema fornito con la BridgeBoard. La 

Ricollegarsi al file che ospita il drive virtuale è semplice; come 
esempio, riconnettiamoci al drive virtuale che abbiamo usato 
per le nostre prove. Battete questa linea: 

funzione di "Fdisk" è spiegata in grande dettaglio nella Parte 3 
- Appendice F del manuale MS-DOS 3.2; per questa ragione, 
piuttosto che riscrivere delle informazioni che potete benissi¬ 
mo trovare da altre parti, preferisco mettervi solamente in gra- 

jlink d: ram:ms-dos 

do di usare Fdisk per creare la partizione per il drive Janus e 
rimandarvi al manuale MS-DOS per ulteriori chiarimenti. 

e premete Return. Vi dovrebbe apparire come risposta: 

Battete "Fdisk" e premete Return. Una volta che il menu è ap- 

VDrive Status Linked to 

parso, scegliete l’opzione 1; dal momento che intendiamo usa¬ 
re parte di questo drive come drive Janus, battete "n" quando vi 

c : 

d: R/W ms-dos 

e : 

f : 

viene chiesto se volete usare l'intero hard disk. A questo punto 
ci viene mostrato il numero complessivo dei cilindri disponibili 
per l’uso (611) e siamo invitati a precisare la dimensione della 
nostra partizione. Poiché vogliamo dividere il drive a metà, 
battete 312 e premete Return. Ci viene poi richiesto il numero 

Come potete vedere, il nostro drive virtuale è di nuovo pronto 
per l’uso. E’ importante che notiate che non ho usato l’opzione 
"/c" questa volta; se lo avessi fatto, avrei perso tutti i dati con¬ 
tenuti nel vecchio file. 

del primo cilindro da assegnare alla partizione che stiamo cre¬ 
ando; battete 0 e premete Return. A questo punto Fdisk ci in¬ 
formerà che la partizione MS-DOS è stata finalmente creata. 
Selezionate allora l’opzione 2; Fdisk vi chiederà di inserire il 
numero della partizione che intendiamo rendere attiva. Battete 

Se usate il comando jlink senza parametri, vi verrà mostrata la 
lista dei nomi di drive disponibili e lo stato di tutti quelli attivi. 
Forse avete già notato che jlink produce una lista di quattro no¬ 
mi di drive e questo avviene semplicemente perchè sono quat¬ 
tro i drive virtuali diversi che il sistema vi consente di usare. Si 
può usare uno qualsiasi dei nomi specificati senza dover rispet¬ 
tare un ordine specifico. Nel caso che abbiate più o meno di 
due drive, la lista inizierà con nomi diversi; infatti la lista inizia 
òol primo nome di drive libero. 

”1" e premete Return. Con questo abbiamo terminato di usare 
Fdisk e per uscire possiamo usare il tasto Esc; una volta usciti, 
è necessario fare nuovamente il boot della BridgeBoard. 

Compiuta questa operazione, accingiamoci a creare una parti¬ 
zione per il drive Janus. Battete "Adisk" e premete Retum; vi 
dovrebbe comparire una serie di messaggi e di opzioni simili a 
quelle presenti in Fdisk. I messaggi ci informano che al mo¬ 
mento non ci sono partizioni gestite da Amiga, che il numero 
complessivo di cilindri disponibili è 611 e che c’è una partizio- 

Lasciatemi concludere l’argomento dei drive virtuali con un 
accenno all'opzione "/r". Questa opzione, se usata alla creazio- 

ne MS-DOS attiva. Questa partizione MS-DOS ha inizio col 
cilindro 0 e termina al cilindro 311. Scegliete l’opzione 3. Ci 

noi 
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viene allora comunicato il numero di cilindri disponibili (298) 
e il numero del primo cilindro libero (312). Seguendo le indi¬ 
cazioni, battiamo 298 e 312; fatto questo, Adisk ci informerà 
che ora la partizione numero due è una partizione Amiga con 
inizio al cilindro 312 e termine al cilindro 611. La divisione 
nelle due partizioni da 311 e 298 cilindri non è proprio a metà 
esatta, ma gli si avvicina sufficientemente. Anche in questo ca¬ 
so, usate il tasto Esc per uscire e date subito il reset della Brid- 
geBoard. 

Il passo successivo consiste nella formattazione delle due parti¬ 
zioni del nostro hard disk. Per far questo, aprite la finestra PC e 
battete il comando seguente; 

format c: /v /s 

e premete Return. Il sistema correttamente ci avverte che tutti i 
dati presenti sul disco "non-removable", cioè sullo hard disk, 
verranno cancellati. Premete "y" e quindi Return per prosegui¬ 
re nell’operazione. A questo punto viene formattata la sola par¬ 
tizione MS-DOS; quando l’operazione è terminata, ci viene 
richiesto un nome per il volume creato. Battete il nome che 
avete scelto e premete Return. La partizione MS-DOS è ora 
pronta per l’uso. 

Passiamo ora dalla parte AmigaDOS e apriamo una finestra 
CLI. Se non avete familiarità con il CLI, è consigliabile che 
leggiate il vostro manuale di Amiga. Battete "DJmount" e pre¬ 
mete Return. Dopo pochi secondi dovrebbe apparire un reque- 
ster che vi informa che il vostro hard disk non è un disco DOS. 
Ignorate del tutto questo messaggio e scegliete col mouse 
"Cancel". Battete la linea seguente: 

DPformat drive jhO: name "Nome scelto" 

dove al posto di "Nome scelto", mettete il nome che avete ef¬ 
fettivamente scelto per la partizione AmigaDOS. Dopo che 
avete premuto Return, apparirà un requester che vi chiede di 
inserire un disco, ma poiché il disco è già presente, ignorate il 
messaggio e premete Return. Il sistema formatterà ora la parti¬ 
zione AmigaDOS, ovvero il drive Janus. Al termine della for¬ 
mattazione, ritorna il solito prompt del CLI e nel Workbench 
appare una nuova icona per il drive Janus appena creato. 

Ciò che ora rimane da fare è far sì che il drive Janus si monti 
automaticamente all’accensione e durante la fase di boot. Dal 
CLI battete: 

ed df0 :s/startup-sequence 

Mettete una copia del vostro disco di sistema nel drive dfO: e 
premete Return. Quando la finestra di ED si è aperta, muovete 
il cursore esattamente alla destra della "s" del comando "Bin- 
dDrivers". Premendo ora Return si apre una nuova linea; in ta¬ 
le linea battete "DJmount" e premete il tasto Esc. Apparirà un 
asterisco nell’ultima linea dello schermo; battete "x" e Return. 

Avendo inserito il comando DJmount nella startup-sequence, 
cioè nella sequenza di comandi che vengono eseguiti ogni vol¬ 
ta che viene fatto ripartire il sistema, il drive Janus si monterà 


automaticamente durante la fase di boot. In compenso questo 
comporta un’attesa di circa un minuto e mezzo ogni volta che 
viene fatto il boot. 

Ciò esaurisce l’argomento dei drive Janus. Giunti a questo 
punto, dovreste ormai iniziare a sentirvi degli esperti della 
BridgeBoard! 

Il trasferimento di file 

L’ultima parte di questo articolo è dedicata a esaminare le di¬ 
verse maniere per trasferire file tra AmigaDOS e MS-DOS. Ci 
sono diverse utility già pronte per questo scopo; alcune sono 
fornite direttamente con Amiga, alcune con la BridgeBoard e 
altre sono programmi commerciali disponibili presso i rivendi¬ 
tori. 

E importante tenere a mente che poter trasportare un file bina¬ 
rio ovvero un programma da un sistema all’altro non significa 
assolutamente che quel programma funzioni, anzi questo non 
capita mai. I trasferimenti di cui ci occupiamo non comportano 
alcun tipo di conversione e in generale hanno senso solo per fi¬ 
le di testo. 

Iniziamo ad esaminare le PCutils. Queste utility sono state pro¬ 
dotte dalla Commodore e inserite nell’Enhancer Kit della ver¬ 
sione 1.2 di AmigaDOS; attualmente vengono fornite come 
corredo software con ogni Amiga. Le PCutils consistono in 
due programmi, PC Format e PC Copy, e funzionano con di¬ 
schi da 5.25" formattati sotto MS-DOS a 360K e solo con il 
drive A1020. L’uso di PCutils non consente che LA1020 ven¬ 
ga montato, cioè reso disponibile per l’uso con AmigaDOS. 

PC Format permette di formattare un disco MS-DOS col drive 
A1020 e risulta molto comodo perché vi evita di ricorrere al¬ 
l'uso della BridgeBoard qualora, ad esempio, vogliate trasferi¬ 
re dei file e vi siete scordati di formattare un disco MS-DOS. 
L’uso di PC Format è estremamente semplice: dopo aver atti¬ 
vato col mouse l’icona di PC Format, vi appare una finestra 
con i valori di default delle opzioni. Potete cambiare a vostro 
piacimento le opzioni e inserire il nome di volume che deside¬ 
rate; in generale, comunque, non avrete alcun bisogno di alte¬ 
rare i valori di default. 

PC Copy è il programma più usato dei due che compongono le 
PCutils. PC Copy può copiare sia file di testo sia file binari. Ci 
sono due opzioni specifiche per i file di testo; Text-7 e Text-8 
sono due "filtri gadget" che assicurano che i file copiati siano 
convertiti correttamente per l’impiego con l’altro sistema ope¬ 
rativo. PC Copy può infatti essere usato per leggere e scrivere 
tanto i dischi MS-DOS quanto quelli AmigaDOS. 

Quando viene lanciato PC Copy, le opzioni sono predisposte 
per la copia di file binari dal 1020 al formato AmigaDOS. Se 
intendete copiare file di testo, dovete cambiare oppotunamente 
l’opzione di filtraggio. Se quando avete lanciato PC Copy non 
avevate posto un disco nel 1020 o se nel frattempo avete cam¬ 
biato il disco, clickate sulle parole "Disk Change" nell’angolo 
in basso a sinistra per informarne PC Copy. Se il disco MS- 
DOS che state usando contiene file nascosti, clickate sulla pa¬ 
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rola "Hidden" al centro nella parte bassa dello schermo e tali 
file vi verranno mostrati. Se desiderate copiare da AmigaDOS 
a MS-DOS, clickate all’intemo della finestra "From: - To:". 
Questo scambierà il drive di destinazione con quello di sorgen¬ 
te. Quando copiate da AmigaDOS a MS-DOS avete poi tre ul¬ 
teriori opzioni, la cui attivazione è controllata da un menu 
"pull-down". Queste opzioni sono: Read-Only, Hidden e Sy¬ 
stem. Se non avete idea di che cosa queste parole significhino, 
potete trovare tutte le spiegazioni del caso, come al solito, sul 
manuale MS-DOS 3.2. Questo è quanto è utile sapere sulle 
PCutils, per cui se avete un drive A1020, provate a dar loro 
un’occhiata; non saranno proprio le migliori, ma dal momento 
che sono praticamente gratis, hanno un ottimo rapporto prezzo- 
prestazioni. 

Passiamo ora a considerare le utility ARead e AWrite fornite 
sul disco MS-DOS con la BridgeBoard. E' bene sottolineare 
che affinché ARead e AWrite possano funzionare bisogna pri¬ 
ma far eseguire il comando PCdisk, che ho già menzionato nel 
paragrafo relativo ai drive virtuali. 

ARead copia un file AmigaDOS in un file MS-DOS. Il file 
AmigaDOS può essere contenuto in un qualsiasi device ricono¬ 
sciuto da AmigaDOS e quindi sui floppy disk, sugli hard disk, 
nel RAM disk e così via. Il file destinazione può invece risie¬ 
dere in un qualsiasi device MS-DOS. Il seguente esempio chia¬ 
risce la sintassi del comando: 

ARead df0 :s/startup-sequence A: test.txt 

In questo caso, il comando ha come effetto quello di copiare il 
file di Amiga "startup-sequence" dalla directory "s" del drive 
"dfO:" nel drive MS-DOS "A:" con il nome di "test.txt". A que¬ 
sto riguardo, è opportuno far notare che la Commodore si è di¬ 
menticata nel manuale della BridgeBoard di precisare che nel 
caso in cui vogliate copiare un file binario, dovete aggiungere 
l’opzione "/B" alla fine della linea del comando. A puro titolo 
di esempio, per copiare il file eseguibile "echo" (che non fun¬ 
ziona su MS-DOS, ovviamente!) si deve dare il seguente co¬ 
mando: 

ARead dfO:c/echo A: echo.exe /B 

AWrite fa l’opposto di ARead; trasferisce infatti un file dal¬ 
l’ambiente MS-DOS all’ambiente AmigaDOS. Per AWrite 
valgono le stesse considerazioni fatte per ARead. Un esempio 
del suo impiego è il seguente: 

AWrite A:autoexec,bat dfO:testfile 

Il risultato è che il file "autoexec.bat" contenuto nel drive "A:" 
viene trasferito in ambiente AmigaDOS sul drive "dfO:" col no¬ 
me di "testfile". Anche nel caso di AWrite bisogna usare l’op¬ 
zione "/B" quando si copiano file binari. 

Un impiego interessante di AWrite consiste nel trasferire file di 
testo da MS-DOS alla stampante di Amiga. La sintassi è que¬ 
sta: 

AWrite A:autoexec.bat prt: 


Il vantaggio di usare AWrite al posto del programma "LPT1" 
sta nel fatto che in questa maniera si può usare Preferences per 
controllare il tipo di stampa o per usare una qualunque delle 
stampanti che Amiga può pilotare. 

Diamo ora un’occhiata a Dos-2-Dos. Dos-2-Dos è un program¬ 
ma commerciale che, come PC Copy, gira sotto AmigaDOS e 
può impiegare il drive 1020. Le somiglianze, però, si fermano 
qui. Dos-2-Dos, infatti, può leggere e scrivere dischi MS-DOS 
sia da 5.25" che da 3.5", da 360K o 720K. 

Dos-2-Dos è molto semplice da usare e ha il solo difetto di par¬ 
tire solo da CLI. Non intendo spiegare qui come usare Dos-2- 
Dos, dal momento che ciò è ampiamente spiegato nel manuale 
che accompagna il programma. I vantaggi principali di Dos-2- 
Dos rispetto a PC Copy sono la possibilità di usare qualsiasi 
drive, anche se già montato, e la possibilità di leggere e scrive¬ 
re i dischi MS-DOS da 3.5". Queste due peculiarità possono 
giustificare senz’altro l'acquisto del programma. 

Nota: Dos-2-Dos fornisce anche un’altra curiosa possibilità: 
quella di leggere e scrivere anche dischi formattati con l’Atari 
ST. 

L’ultimo programma che intendo menzionare in questa breve 
rassegna dei programmi di trasferimento file si chiama "Project 
D". Project D è una utility di backup per Amiga con un nuovo 
accessorio chiamato Omni Copy. Omni Copy è diverso dalle 
utility di cui ho parlato in precedenza; in particolare, non copia 
file da un sistema operativo all’altro. Omni Copy, infatti, si li¬ 
mita a copiare dischi del medesimo DOS: anche su formati di¬ 
versi e con più drive destinazione. 

Per rendersi conto delle possibilità che Omni Copy offre, con¬ 
siderate la seguente situazione: voi avete un Amiga con un dri¬ 
ve 1020 e un vostro amico ha un 500 con il Transformer. 
Questo vostro amico vorrebbe far andare il Transformer sul 
suo 500, ma non ha un disco di boot MS-DOS da 3.5". D'altro 
canto, possiede un PC compatibile e quindi ha sicuramente un 
disco di boot MS-DOS da 5.25". Ciò che il vostro amico deve 
fare è portarvi il disco di boot da 5.25" e un disco da 3.5" vuo¬ 
to; con Omni Copy, infatti, potete trasferire il contenuto del di¬ 
sco MS-DOS da 5.25" nel disco da 3.5", sempre in formato 
MS-DOS. 

Ovviamente Omni Copy copia anche da 3.5" a 3.5" e da 3.5" a 
5.25"; con un solo programma, quindi, potete trasferire libera¬ 
mente il contenuto dei dischi di formato diverso. Consideran¬ 
do, poi, che Project D è venduto sostanzialmente come utility 
di backup per Amiga, le possibilità offerte in aggiunta e la ver¬ 
satilità di Omni Copy non possono che rendere questo prodotto 
molto interessante. 

Sani e salvi alla meta 

Siete riusciti ad arrivare al termine della guida all’esplorazione 
della BridgeBoard. Spero che la conoscenza che avete acquisi¬ 
to in questo viaggio si dimostri utile per evitare eventuali pro¬ 
blemi e che serva per farvi apprezzare pienamente le qualità 
della BridgeBoard. 
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La vita, Vuniverso...e la legge di Sturgeon 


di Larry Phillips 

Larry Phillips, di Vancouver, British Columbia, si occupa di 
hardware e software per passione. È anche SysOp nei Compu¬ 
Serve' s Amiga Forum. 

Qualcuno una volta ha detto all’autore Theodore Sturgeon: "il 
novanta per cento della scienza è costituito da fesserie". La ri¬ 
sposta di Sturgeon ha colpito nel segno. Disse: "il novanta per 
cento di tutto è costituito da fesserie". 

Questa piccola raffinatezza fin da allora è conosciuta come la 
Legge di Sturgeon, e a seconda del vostro punto di vista può 
essere più o meno vera. La cosa importante è che è il vostro 
punto di vista che determina la veridicità o la falsità della Leg¬ 
ge di Sturgeon poiché si adatta a qualsiasi cosa la applichiate. 

Recentemente ho avuto l’occasione di rispondere a un com¬ 
mento su di un prodotto che presto sarà in vendita per l’Amiga. 
Ero completamente contrario a tale commento. Prima di 
esporre il commento o le ragioni del mio disaccordo voglio da¬ 
re alcune informazioni precedenti. 

Gli interpreti PostScript vengono di solito inseriti nella stam¬ 
pante, come ad esempio la NEC LC-890 o la LaserWriter della 
Apple, oppure in una compositrice come la Linotron. Il codice 
PostScript viene mandato alla stampante e viene avviato attra¬ 
verso l’interprete che si trova alLinterno della stessa. Questo 
produce un output alla risoluzione del dispositivo di output, 
che può andare da 300 DPI (Dots Per Inch/Punti per pollice) 
per le stampanti laser, a 1200 DPI o 2540 DPI per la Linotron. 

Il PostScript permette la definizione di oggetti che sono indi- 
pendenti dalla risoluzione della periferica. Questi possono es¬ 
sere oggetti geometrici come cerchi, quadrati, linee, o una 
combinazione degli stessi. Si può trattare di caratteri individua¬ 
li in un font particolare di tutte le dimensioni che volete. 

A causa della natura indipendente della risoluzione PostScript, 
l’output di una periferica che può lavorare in PostScript appari¬ 
rà della miglior qualità possibile per quella periferica. Una 
stampante laser a 300 DPI non produrrà un output buono come 
quello della Linotron a 1200 DPI, e l’output della Linotron a 
2540 DPI sarà ancora migliore. Questa indipendenza nella ri¬ 
soluzione è sfruttata dai compositori e dal settore dell’editoria. 


Date un'occhiata alla pagina che state leggendo in questo mo¬ 
mento. Notate la qualità dei caratteri, i bordi, i diversi font usa¬ 
ti. Questa pagina è stata prodotta in PostScript, tutta, compresi 
i bordi. 

Molte editorie non possiedono una Linotron. Sono macchine 
molto costose (circa 100 milioni - nde), ed inoltre non sono ne¬ 
cessarie allo scopo di comporre libri o riviste, quindi la spesa 
sarebbe inutile. 

Le editorie potrebbero utilizzare una stampante laser in grado 
di lavorare in PostScript collegata ad un Amiga. La risoluzione 
a 300 DPI è sufficientemente adatta a molti scopi. Sicuramente 
è in grado di dire all’editore come apparirà una pagina; sì può 
vedere in anticipo il prodotto della pagina e quindi sapere che 
quando appare corretta, apparirà nello stesso modo su di una 
compositrice più costosa. 

I compositori sono persone molto pignole quando si parla in 
termini di qualità di stampa. Sono in grado di dire quasi imme¬ 
diatamente quale risoluzione è stata usata per produrre un libro 
o una rivista. Vi diranno anche che una risoluzione a 300 DPI 
non è sufficiente e che la risoluzione a 1200 DPI è l’unica pos¬ 
sibile per avere determinati risultati. 

Avete mai osservato l’output di una stampante laser che lavora 
in PostScript? E probabile che abbiate pensato che fosse un ri¬ 
sultato maledettamente buono, forse persino eccellente, ma so¬ 
lo se non siete un compositore. 

Tutto dipende dal vostro punto di vista. Dopo avervi dato suffi¬ 
cienti informazioni anche voi potreste osservare che una stam¬ 
pante a 300 DPI è veramente inutile. 

Ritornando al commento, una società chiamata Pixelations spe¬ 
ra di mettere sul mercato un prodotto nel prossimo febbraio, 
chiamato PrintScript, un interprete PostScript, ma con una dif¬ 
ferenza. Eseguirà tutto il lavoro sulla memoria del vostro Ami¬ 
ga invece che nella memoria di una costosa stampante laser, 
inoltre eseguirà il lavoro alla risoluzione di cui avete bisogno 
per la vostra stampante, il che significa che potete dare l’output 
in PostScript alla vostra stampante, che normalmente non è in 
grado di lavorare in PostScript, la quale può essere a 9 aghi, 24 
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aghi, a getto d'inchiostro o persino laser. 

In pratica prenderà il codice PostScript e costruirà una bitmap 
che coincida con le capacità della vostra stampante, poi invierà 
il codice alla stampante come un dump grafico. Questo è esat¬ 
tamente ciò che fà una stampante PostScript, ma una stampante 
ad aghi sarà molto più lenta ed avrà una risoluzione inferiore, 
sebbene alcune stampanti ad aghi possano avere una risoluzio¬ 
ne di 360 DPI; tuttavia i loro punti sono più sfuocati. 

Lo stesso codice PostScript può essere creato manualmente, 
con un editor, oppure con un programma come Professional 
Page. Il costo di PrintScript sarà di $89, e non si trova perciò 
nella fascia dei prezzi che voi attribuireste solitamente al soft¬ 
ware professionale. 

Il commento si basava sul fatto che inizialmente PrintScript sa¬ 
rebbe uscito sul mercato con due soli font, molto simili al Ti¬ 
mes e all’Helvetica, due dei font più popolari disponibili sulle 
stampanti PostScript. 

La persona che ha fatto il commento è un professionista, prob¬ 
abilmente un compositore, si riferiva al fatto che "tutti perde¬ 
vano tempo attorno ad un programma PostScript che non 
aveva come supporto una vasta scala di font standard". Dal suo 
punto di vista, quello cioè di un professionista, ha perfettamen¬ 
te ragione. 

Ma qual'è invece il punto di vista delle altre persone, del dilet¬ 
tante, delle persone che vogliono stilare bollettini di informa¬ 
zione saltuari, le etichette degli indirizzi o lettere d'affari? 

Per me è sempre stato un mistero il fatto che potessero esistere 
certi prodotti, normalmente molto costosi, fatti invece in modo 
da poter avere dei prezzi ragionevoli, con meno caratteristiche 
e di qualità inferiore. 

Nessuno penserebbe mai di usare una telecamera della Mattel 
per registrare un programma televisivo, tuttavia molte di queste 
telecamere vengono vendute ai bambini. A loro importa il fatto 
che vi siano lenti di plastica e che la qualità video sia scarsa? 
No, certamente no. Riprendono i loro amici facendogli fare co¬ 
se sciocche, generalmente si divertono un mondo e la spesa è 
ricompensata. 

Vi sono molti esempi che potrei citare, dalle economiche mac¬ 
chine fotografiche di plastica agli stereo composti da due regi¬ 
stratori. un piatto incorporato, sintonizzatore, amplificatore e 
casse, tutto per 59 dollari e 95 centesimi. 

Per il software è la stessa cosa. PageSetter era un programma 
interessante poiché era diretto al mercato casalingo. Alcuni 
pensavano che fosse un programma scarso perché non offriva 
le caratteristiche e la qualità professionale dell’output, ma io 
penso che non abbiano colto il punto della questione. Profes¬ 
sional Page è il programma che volevano, e non ho mai sentito 
nessuno lamentarsi di questo, eccetto per il fatto che costa trop¬ 
po. 

Sotto questo aspetto il software è uguale alThardware. Ci vo¬ 


gliono molti soldi per poter offrire varie caratteristiche e la 
qualità, e non ci si può aspettare di avere il miglior software a 
prezzi bassi. 

La tecnica è la stessa sia quando si acquistano dei prodotti soft¬ 
ware che dei prodotti hardware. Decidete che cosa volete che il 
pacchetto faccia e poi cercate quello che corrisponde alla vo¬ 
stra disponibilità economica. 

PrintScript sarà in grado di soddisfare le necessità. Tali neces¬ 
sità riguardano la capacità di produrre il miglior output che la 
vostra stampante sia in grado di effettuare, e lo farà ad un prez¬ 
zo ragionevole. In seguito sarà dotato di più font ed inoltre ac¬ 
quisterà senza dubbio altre caratteristiche. 

Il fatto che attualmente non sia uno strumento professionale è 
dovuto alla dichiarazione di un professionista che lo ha am¬ 
mucchiato insieme a quel novanta per cento di cui parla Theo- 
dore Sturgeon, ma per l’utente casalingo o occasionale 
PrintScript fa parte di quel dieci per cento che non è spazzatu¬ 
ra. Vi saranno tuttavia coloro che si aspetteranno di più, i quali 
si lamenteranno della perdita di tempo. 

L'unico problema riguardante la questione del punto di vista, 
nasce per quei prodotti che mirano al settore professionale e 
che sono pubblicizzati come tali, mentre si tratta di prodotti de¬ 
stinati poco più che al mercato casalingo. 

Non mi importa se la qualità del mio programma CAD non è a 
livello dei programmi professionali perché soddisfa i miei bi¬ 
sogni limitati e costa molto meno dei programmi a livello pro¬ 
fessionale. 

Se fosse stato pubblicizzato come programma a livello profes¬ 
sionale probabilmente ne sarei rimasto deluso, e l’acquirente 
che avesse avuto bisogno di un programma a livello professio¬ 
nale certamente avrebbe fatto lo stesso, qualsiasi fosse stato il 
prezzo. 

Penso che se una società si consultasse con dei professionisti e 
si preoccupasse di descrivere il suo prodotto accuratamente, 
piuttosto che rischiare l’ira di coloro che richiedono le caratte¬ 
ristiche descritte in maniera pomposa e risplendente sul prodot¬ 
to. porterebbe alla stessa società grossi vantaggi. 

In conclusione, cosa possiamo dire dell’applicazione della 
Legge di Sturgeon all’attuale linea di prodotti software per 
Amiga? Beh, se avete necessità professionali la Legge di Stur¬ 
geon è vicina alla verità, sebbene sia un po’ conservatrice. Se 
invece fate parte degli utenti casalinghi medi allora il novanta 
per cento va probabilmente ridotto di uno o due fattori. 

Se siete sviluppatori di software, perché non passare in rivista 
attentamente i vostri prodotti, con l’aiuto di un professionista 
nel settore adeguato, e chiamarli con il loro vero nome? 

Non abbiate paura di fornire un prodotto diretto al mercato ca¬ 
salingo, semplicemente chiamatelo come tale, ed usatelo come 
base per uno sviluppo futuro. 
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MS-DOS e FFS rivisitati, e un occhiata al software per l’A500 


di Don Curtis 

Don Curtis è un funzionario di polizia di Denver, in Colorado. 
Negli ultimi due anni è stato assegnato alla progettazione e al¬ 
lo sviluppo di programmi oltre che alla progettazione ed alla 
manutenzione di sistema di IO computer AT&T Unix 3B2. Du¬ 
rante il tempo libero Don è assistente Svsop nei CompuServe’s 
Amiga Forum. 

Come ormai avrete notato, l'ultima volta vi ho dato un’infor¬ 
mazione errata. Ho descritto un metodo con il quale avreste 
potuto usare il nuovo Fast Filing System (FFS) su di una parti¬ 
zione MS-DOS dell'Hard Disk per Amiga (drive JANUS). 

Come vi ho detto nel precedente articolo, non avevo verificato 
tutte le procedure da me descritte, ma pensavo provenissero da 
fonti attendibili. In questo caso particolare l'informazione pro¬ 
veniva direttamente da uno dei programmatori software della 
Commodore. Per dirla in parole povere: si sbagliava. 

Ho un A2000 fornito di Bridge Board e di hard disk (10 Mega¬ 
byte) sulla partizione MS-DOS, ma ho anche un hard disk sulla 
partizione Amiga quindi non ho bisogno di usare un drive JA¬ 
NUS. Oltre tutto utilizzo tutti i 10 Megabyte per la parte MS- 
DOS. Dunque, per farla breve, qualcuno mi ha riferito di aver 
provato ad usare FFS su di un hard drive JANUS e che il drive 
non riusciva ad eseguire il format. Il sintomo riportato riguar¬ 
dava il programma format, il quale iniziava nella maniera cor¬ 
retta ed in seguito si fermava semplicemente dopo aver 
formattato il primo cilindro. Niente, nessun messaggio di erro¬ 
re, nessuna attività, solo un programma bloccato. 

Ho pensato che ci dovessero essere dei problemi nella sua 
mountlist o nella procedura usata, quindi ho fatto un backup 
del mio drive MS-DOS ed ho provato ad avviare il FFS su di 
un drive JANUS. 

Alcuni problemi: la formattazione è iniziata ma poi si è blocca¬ 
ta. Ho controllato, cambiato i parametri nella mountlist ed ho 
utilizzato un editor di settore per cercare di capire cosa stesse 
effettivamente succedendo nel drive. Quella sera devo aver av¬ 
viato FDISK e ADISK. riavviato la macchina, effettuato il 
ntount e così via per almeno trenta volte, cercando di farlo fun¬ 
zionare. Sapevo che la procedura che avevo dato era vicina a 
quella corretta, il drive stava effettuando il giusto tipo di attivi¬ 


tà ed il primo cilindro risultava in realtà formattato, ma niente 
di più. 

Ho notato un'unica stranezza, il normale programma format. 
DPFormat, cominciava sempre dal cilindro 0 invece che dal ci¬ 
lindro 105, il cilindro dal quale effettivamente partiva la parti¬ 
zione JANUS. Naturamente DJMount e DPFormat funzio¬ 
navano alla perfezione, ma non era quello che volevo. 

Quello era solo l'indizio numero uno per riuscire a far funzio¬ 
nare il FFS. Mentre potevo avere accesso al drive, se davo l'or¬ 
dine di effettuare un mount sullo stesso il mio editor di settore 
non mostrava le dimensioni del drive e il numero dei settori. 
Continuando a sbizzarrirmi con l’editor di settore e con degli 
ordini nella mountlist, sembrava che, per l'Amiga, il drive JA¬ 
NUS fosse un drive completamente separato, non una partizio¬ 
ne su un drive. 

Cambiando i numeri dei cilindri nella mia mountlist, in modo 
che combaciassero con quelli dati da DPFormat una volta av¬ 
viato, ha risolto quel problema. Ora, se ho usato DJMount per 
effettuare il mount del drive e DPFormat per formattarlo, avrei 
potuto semplicemente usare il comando normale Amiga 
MOUNT invece che DJMount, pur utilizzando il drive. Sfortu¬ 
natamente non mi ha aiutato a risolvere il problema del format. 
Continua a bloccarsi. 

L'indizio numero due è stato il modo in cui il filesystem identi¬ 
fica un disco. La differenza tra l’Old File System (OFS) e il 
FFS è il modo in cui i settori dei dati vengono utilizzati. L'OFS 
usa solo 488 byte dei 512 disponibili per i dati, gli altri 24 byte 
riguardano le informazioni del filesystem, principalmente quel¬ 
le sull’eventuale recupero. 

Il FFS rinuncia al recupero dati ma utilizza tutti i 512 byte per i 
dati. Tuttavia le intestazioni della root directory, delle directory 
e dei file sono identiche sia nell'OFS che nel FFS. 

L'AmigaDOS usa un marker nel settore 0 del filesystem per 
indicargli di che tipo di disco si tratta. Un disco KickStart uti¬ 
lizza i caratteri ASCII KICK come identificazione. Un disco 
OFS usa i caratteri ASCII DOS, oltre ad un byte contenente il 
valore 0 come suo segno di identificazione (DOSO). Un disco 
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chio drive da 10 Megabyte, con un tempo medio di seek di 95 
millisecondi sul lato MS-DOS. Se voi possedete un drive più 
veloce (oggi quasi tutti lo sono), suppongo che possiate ottene¬ 
re cifre ancora più soddisfacenti. 

Che ne dite adesso di un vero test? Ho fatto una copia di tutti i 
file che si trovano sull’hard disk Amiga sul drive JANUS uti¬ 
lizzando il comando COPY con l’opzione ALL. Poiché questa 
era una partizione di soli 5 mega non sarebbe stata in grado di 
tenere tutti i file, così l’ho predisposta in modo che potesse sta¬ 
re nel drive JANUS. Usando OFS ho impiegato 8 minuti e 40 
secondi a riempire il drive. Usando invece FFS sono bastati 6 
minuti e 30 secondi, e poiché il FFS usa tutti i 512 byte di dati 
per blocco, ha anche copiato 32 file addizionali (5%) nel drive. 

Il caricare e lanciare programmi ci mostra che il FFS sul drive 
JANUS è stato molto più veloce dell’OFS. Ho avviato altri test 
per assicurarmi che le partizioni del drive Amiga o MS-DOS 
non avessero problemi Luna con l'altra. In effetti non ne ave¬ 
vano. Gli editor di settore mostravano che, in entrambe le par¬ 
tizioni. tutti i dati si trovavano dove si presupponeva che 
fossero. 

Tuttavia ho scoperto una cosa: non cercate di usare la partizio¬ 
ne MS-DOS durante l'attività del disco JANUS, lo mettereste 
in ginocchio! Lo MS-DOS non riesce semplicemente a com¬ 
prendere il concetto di fare due cose contemporaneamente, co¬ 
sa che invece faccio spesso sulla partizione Amiga. Se avete 
Transformer, il programma di simulazione del software MS- 
DOS, sapete quanto è lento. Bene, se cercate di usare il MS- 
DOS ed accedere al drive JANUS allo stesso tempo, sarà dieci 
volte più lento di Transformer! 

Riassumendo: Il FFS funziona su di un drive JANUS, ma non 
come ho detto che dovrebbe fare nel il mio ultimo articolo. Ri¬ 
cordate, dovete avere un editor di settore. Ecco come usare il 
FFS su di un drive JANUS (probabilmente vi sono altri modi, 
solo che non li ho ancora scoperti): 

1 Fate un backup di tutto quello che avete sulla partizione MS- 
DOS e sulla partizione Amiga, se già possedete una partizione 
JANUS. 

2 Se non possedete ancora una partizione JANUS, ripartite la 
partizione del drive MS-DOS usando i comandi MS-DOS 
FDISK e ADISK, non dimenticate di assicurarvi che FDISK 
renda attiva la sua partizione. Dovrete riavviare la macchina 
dopo aver utilizzato FDISK e ADISK, quindi ci vuole un po’ 
di tempo. 

3 Dopo aver avviato l’Amiga usate DJMount per effettuare il 
mount della partizione Amiga. 

4 Usate DPFormat per formattare la partizione Amiga e mentre 
la formattazione è in corso, scrivetevi i numeri del cilindro bas¬ 
so e di quello alto. Questo è molto importante! DOVETE for¬ 
mattare il drive; anche se il vostro drive JANUS è settato 
sull’OFS, dovete riformattarlo. 

C’è una bella differenza! E questo è stato ottenuto con un vec- 5 Con un editor di settore andate al blocco 0 del drive. Notere- 


FFS utilizza gli stessi caratteri DOS oltre ad un byte contenen¬ 
te il vaiorei (DOSI) come suo segno di identificazione. Ricor¬ 
date che non si tratta delle stringhe "DOSO" e "DOSI" ma 
delle stringhe "DOS" seguite dal valore 0 o 1. 

Adesso, avendo la mountlist corretta, se eseguivo il mount sul 
drive come drive FFS, ottenevo il requester "Not a Dos Disk". 
Se invece eseguivo il mount sul drive come drive OFS, funzio¬ 
nava alla perfezione. Entrambi i filesystem riconoscevano il di¬ 
sco, il programma format non funzionava sia usando OFS che 
FFS ma, una volta formattato, OFS funzionava perfettamente. 
Che cosa sarebbe accaduto se avessi cambiato il segno di iden¬ 
tificazione del FFS? FFS avrebbe potuto in questo caso usare 
il disco? Certamente! Ho preso quindi il mio editor di settore 
ed ho cambiato il quarto byte da valore 0 a valore 1, quindi l'¬ 
ho trascritto. Ho riavviato la macchina, effettuato il MOUNT 
sul drive con una mountlist FFS e l’ho usato con FFS! Comun¬ 
que FAmigaDOS apparentemente usa solo quei primi quattro 
byte, quindi se avete un editor di settore che richiede che voi 
eseguiate un checksum sul blocco prima di poterci scrivere, 
funzionerà sempre. 

Questo è stato l’ultimo passo. E un rimedio un po’ raffazzona¬ 
to, ma funziona. Dovrete passare attraverso numerosi stadi, ma 
alla fine ne varrà la pena. L’unico programma di formattazione 
che sembra funzionare su di un disco JANUS è DPFormat, il 
quale capisce solo l'OFS. Il FFS capisce solo un tipo di disco 
DOSI, ma in questo caso l'OFS ed il FFS sono abbastanza si¬ 
mili a quel tipo; formattando sotto OFS e cambiando il disco in 
disco DOSI vi permette di utilizzarlo con il FFS. 

Per esserne certo ho avviato alcuni testi utilizzando Diskperf, e 
mi ha dato i seguenti risultati per OFS: 

File create/delete: 



create 

9 files/sec delete 

16 files/sec 

Directory scan: 

51 entries/sec 




Seek/Read test: 

49 seek/reads 

per 

sec 


r/w 

speed: 

buf 512 byte, 

rd 

20641 

byte/sec 




wr 

17476 

byte/sec 

r/w 

speed: 

buf 4096 byte, 

rd 

20480 

byte/sec 




wr 

17133 

byte/sec 

r/w 

speed: 

buf 8192 byte, 

rd 

20164 

byte/sec 




wr 

16487 

byte/sec 


Non cambia molto, e notate che le dimensioni del buffer più al¬ 
to non variano quasi. Ora proviamo la stessa cosa con FFS: 


File create/delete: 



create 

8 files/sec delete 

12 files/sec 

Directory scan: 

106 

entries/sec 



Seek/Read test: 

57 s 

ieek/read ; 

per : 

sec 


r/w 

speed: 

buf 

512 byte, 

rd 

23405 

byte/sec 





wr 

21845 

byte/sec 

r/w 

speed: 

buf 

4096 byte 

/ rd 

68985 

byte/sec 





wr 

55775 

byte/sec 

r/w 

speed: 

buf 

8192 byte 

, rd 

68985 

byte/sec 





wr 

56987 

byte/sec 
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te che l’identificazione DOSO si trova nei primi 4 byte. Cam¬ 
biate il byte 4 da 00 a 01. 

6 Adesso create una mountlist per il vostro nuovo drive. Potete 
chiamarla come volete, anche JHO:. Usate la mountlist di 
esempio a pagina A-3 deH'"Enhancer Manual", ma cambiate il 
device con il nome jdisk.device. Cambiate il numero dell’unità 
in 0 per la prima partizione. Cambiate le Surfaces (superfici) 
ed i BlocksPerTrack (blocchi per traccia) perché vadano d’ac¬ 
cordo con il vostro drive. Cambiate il LowCyl (cilindro basso) 
in modo che combaci con il numero basso dato da DPFormat e 
cambiate l’HighCyl (cilindro alto) in modo che corrisponda al 
numero del cilindro alto dato da DPFormat. Ecco come appari¬ 
va la mia mountlist: 

JHO: 

Device = jdisk.device 
Unit = 0 
Flags = 0 
Surfaces = 4 
BlocksPerTrack = 17 
Reserved = 2 

Interleave = 0 /* tenete questo a 0*/ 

LowCyl = 0 
HighCyl = 153 
Buffers = 20 
Stacksize = 4000 
GlobVec = 1 

FileSystem = L:FastFileSystem 

DosType = 0x444F5301 /* Notate che questo è "DOSI" 
in esadecimale */ 

7 Rimuovete dalla startup-sequence tutti i comandi che si rife¬ 
riscono al drive JANUS, inclusi tutti i comandi DJMount. Non 
li userete più. 

8 Dopo avere salvato la vostra mountlist e la nuova (le nuove) 
startup-sequence, attendete i soliti 3 o 4 secondi e poi riavviate 
l’Amiga. 

9 Dopo l’avvio dello startup effettuate il mount del drive FFS 
JANUS usando il comando mount della versione 1.3. 

10 Eseguite un test del vostro drive - vedete se riuscite ad acce¬ 
dervi. Se avete fatto tutto secondo le regole dovrebbe funziona¬ 
re. Se così è, potete importare nuovamente tutti i file che 
avevate sul drive e poi rielaborare la vostra startup-sequence in 
mount JHO: (o come l’avete chiamato). 

Se non riuscite ad accedere al drive ripercorrete le tappe de¬ 
scritte. Assicuratevi di averle seguite attentamente. Questa pro¬ 
cedura con me ha funzionato benissimo e così è stato per altri 
che l’hanno provata dopo di me. Non ho provato ad usare più 
di una partizione Amiga, ma non vedo ragione per cui non do¬ 
vrebbe funzionare con partizioni multiple JANUS. Fate sem¬ 
plicemente la stessa cosa per ogni partizione (cambiate il 
DOSO in DOS 1 dopo aver effettuato il DPFormat sulla parti¬ 
zione) e poi costituite una sua mountlist. I numeri delle unità 
aumenteranno per ogni partizione, cioè: la prima partizione è 


l’unità 0, la seconda è l’unità 1, e così via. 

Commenti sulle prospettive del software 

Ho dei sentimenti contrastanti riguardo all’attuale stato delle 
cose quando si tratta della quantità e del tipo di software dispo¬ 
nibile per Amiga. Questo include anche i miei pensieri rivolti 
all’A500, perché i due concetti sono dipendenti l’uno dall’al¬ 
tro. Certamente FA500 è un’"ottima cosa" in questo momento. 
E la più popolare delle macchine Amiga e sta vendendo bene. 
Effettivamente si può considerare come la macchina che ha 
permesso alla Commodore di portare ancora il pane a casa. 
L’AIOOO vendeva bene, ma è nulla a confronto con FA500. 
Anche EA2000, nelle sue varie forme, sta vendendo bene, ma 
ancora, non bene come FA500. 

Se le vendite dell’Amiga hanno ormai raggiunto il milione lo 
dobbiamo all’Amiga 500, ed è una buona cosa. La mia preoc¬ 
cupazione non è per oggi, ma per il futuro. A lungo andare 
FA500 potrebbe non essere una "cosa buona". 

L’A500 ha aperto il mercato della linea Amiga a persone che 
godono semplicemente di un'eccellente macchina per giochi a 
un prezzo ragionevole. Questo mi va bene, quelle persone me¬ 
ritano la migliore macchina che sono in grado di acquistare con 
i loro soldi, e sembra che l’Amiga riempia questa nicchia di 
mercato molto bene. 

Non è conveniente espandere la memoria dell’A500, sebbene 
sia possibile, come lo è invece per FA2000 ed i suoi discen¬ 
denti. L’A500 diventa ingombrante quando si aggiungono del¬ 
le parti al corpo centrale. Una scatola che si trova ad un lato 
del sistema, già composto da unità centrale e tastiera, funziona, 
ma non è comodo. Non si può spostare la tastiera per trovare 
una posizione di scrittura più comoda. Non si può sollevare la 
tastiera e metterla sul grembo per potersi rilassare con le gam¬ 
be sulla scrivania (la mia posizione di scrittura preferita quan¬ 
do leggo i messaggi da CompuServe). 

Tutto questo non riduce le qualità del computer, significa solo 
che è un computer non adatto per certe cose. A lungo termine 
significa anche che la maggior parte degli A500 manterrà pra¬ 
ticamente la sua configurazione originale, magari con un se¬ 
condo floppy e un po’ più di memoria. Significa anche che i 
proprietari di A500 non compreranno software che richiede di¬ 
versi Megabyte di memoria e/o grandi hard disk. Naturalmente 
vi saranno delle eccezioni. Vi saranno persone che espanderan¬ 
no il loro A500 a 8 Megabyte di memoria ed aggiungeranno un 
hard disk da 100 Megabyte, tuttavia non sarà quello il tipico 
proprietario di A500. Il tipico proprietario di A500 lo utilizzerà 
per minimi lavori di elaborazione testi, piccoli database casa¬ 
linghi, alcuni lavori video, e molti giochi. 

Per poter vendere al settore professionale abbiamo bisogno di 
software di alta qualità, e non ci giova certo una reputazione 
come produttori di macchine per video giochi. Mentre il ven¬ 
dere al settore professionale può non sembrare vantaggioso, in 
effetti lo è. 

Prendiamo come esempio il mio ufficio. Sebbene io sia asse- 
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gnato all’ufficio dati, dove tutti sviluppiamo programmi a vari 
livelli, vi sono più computer in ufficio che nelle nostre case. 
Non sto parlando di computer principali, parlo dei computer da 
tavolo. Tutti gli undici componenti dell’ufficio hanno sulla loro 
scrivania un computer, ma solo sette di noi hanno un computer 
a casa (due dei quali sono Amiga!). Come succede in molte at¬ 
tività, le macchine che noi utilizziamo sono computer MS- 
DOS. Questo perché il software di cui abbiamo bisogno è 
disponibile e perché queste macchine non hanno la fama d’es¬ 
sere macchine per video giochi. Sicuramente non sono i com¬ 
puter più adatti al nostro lavoro, ma sappiamo che avranno un 
valore oggi come pure domani, è molto semplice. 

In passato ho posseduto computer che avevano la fama d’esse¬ 
re computer per video giochi e sfortunatamente questo ha fatto 
in modo che, dopo poco tempo, i soli programmi disponibili 
fossero i video giochi. Il così detto software serio, per quelle 
macchine, si era prosciugato. Certamente vi erano dei word 
processor disponibili, come pure dei database casalinghi e pro¬ 
grammi di gestione finanziaria, ma la qualità del software serio 
disponibile era scarsa, se non nulla, e vi erano solo tonnellate 
di video giochi. 

Molte persone direbbero: "E allora?". Non hanno bisogno di 
software serio. Probabilmente importa loro ancora di meno il 
fatto di poter vendere al settore professionale, sono compieta- 
mente soddisfatte del software disponibile. Ma vi sono anche 
coloro che notano una grande mancanza nel software Amiga. 
Io non mi occupo di lavori video, ma noto certamente la neces¬ 
sità di un software per coloro che sono interessati al lavoro vi¬ 
deo con l’Amiga. Allo stesso modo, io non mi occupo di video 
giochi, alcune volte gioco ma in generale non ho molto tempo. 
Questo però non significa che non vi siano altre persone che 
desiderano giochi migliori e in quantità maggiore. 

E qui entra in gioco TA500. I produttori conoscono la demo¬ 
grafia, sanno che se la maggioranza dei computer venduti ri¬ 
guarda i modelli a prezzi bassi, con un’espansione limitata il 
software da divertimento venderà di più delle altre forme di 
software. 

Ma c’è anche bisogno di software produttivo. Quello di cui noi 
abbiamo bisogno, in effetti, è un giusto equilibrio nel software 
tra il divertimento e la produttività. Questo è ciò che manterrà 
in buona forma le vendite dell’Amiga. 

Sfogliando gli ultimi numeri delle riviste Amiga, noto una 
quantità terrificante di intere pagine dedicate alla pubblicità di 
video giochi e solo poche pagine di annunci pubblicitari dedi¬ 
cati al software produttivo. Non ho notato un equilibrio, ma per 
ora siamo già a buon punto. 

Quello che voglio dire è che mi piacerebbe poter raggiungere 
quell’equilibrio. L’Amiga è una macchina molto versatile, può 
creare grandi giochi e può anche produrre software incredibile, 
ma il software deve esserci. Sto chiedendo ai produttori e ai 
programmatori di prendere in considerazione il tipo di software 
che offrono. 

Parte del software così detto produttivo che ho visto sull’Ami¬ 


ga è semplicemente spazzatura. Viene pubblicizzato come soft¬ 
ware a livello professionale ed è ingombrante, lento e inflessi- 
bile. Che vantaggi dà un DataBaseX (ragazzi, spero che non 
esista un prodotto con tale nome!) se non è neppure in grado di 
importare un file dBase III? Non dico che debba saper trattare i 
programmi in dBase, ma nessun rappresentante del settore pro¬ 
duttivo si convincerà del fatto che DataBaseX è un programma 
a livello professionale se non è in grado di accettare i suoi dati 
senza dover immettere nuovamente 30.000 record a mano. 

I word processor che impiegano un’ora a stampare una lettera 
perché stampano TUTTE le lettere in grafica ad alta risoluzio¬ 
ne non sono vantaggiosi. Potrebbe andare bene per stampare 
lettere occasionali ad uso casalingo, ma in un’attività dove si 
producono 10 o 20 lettere al giorno non si può aspettare tutto 
quel tempo. Tali attività hanno bisogno di lettere con un forma¬ 
to appropriato, di un’intestazione e di un testo puliti e precisi. 
Hanno il denaro per comperare una stampante di qualità che 
non abbia bisogno di stampare in modo grafico per ottenere te¬ 
sti precisi. Non sto dicendo di non fornire l’output grafico per 
coloro che ne hanno bisogno, ma non ignorate l’output ASCII 
per coloro che possono usarlo. Fate in modo che l’utente possa 
scegliere le sue preferenze, non forzatelo a scegliere le vostre 
preferenze. 

Se avete intenzione di disporre del vostro tempo per creare 
programmi, dedicatene una buona parte alla cura degli stessi. 
Un mese in più passato a "levigare" il programma può fare la 
differenza tra la notte ed il giorno. Prestate ascolto agli utenti, 
scoprite quello di cui hanno bisogno e dateglielo. Osservate 
quello che fate voi, quello di cui avete bisogno per fare il vo¬ 
stro lavoro, e cercate di produrre il software per rendere il vo¬ 
stro lavoro, e quello di tutti coloro che ne svolgono uno simile, 
più semplice. 

Se state scrivendo il programma per un video gioco, bene, ma 
create il miglior video gioco che abbiate mai visto. Poi prende¬ 
te alcuni dei trucchi che avete utilizzato per far funzionare il 
gioco ed applicateli ad un programma di applicazione. Non 
fossilizzatevi, variate la vostra linea di prodotti. A lungo anda¬ 
re, io (l’utente) e l’Amiga saremo tutti vincitori! 

II fatto che TA500 sia il più popolare della linea Amiga non si¬ 
gnifica che ne sia l’unico membro. Non ignoratelo, ma non 
scrivete solo per FA500. Se esiste il software, anche le macchi¬ 
ne più grosse aiuteranno a far salire le vendite. 

L’Amiga è una grande macchina per giocare, ma NON è un 
computer per video giochi. È in grado di fare cose che molti 
non si sarebbero neppure sognati pochi anni fa. Sfruttiamo 
queste capacità in ogni maniera possibile. 
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Linguaggio Assembly 


Parte 1 - il nostro primo programma in linguaggio assembly 


di Jim Butterfield 

.firn Butterfield non ha bisogno di essere presentato. Il suo no¬ 
me costituisce un punto di riferimento fra gli entusiasti utenti 
Commodore di tutto il mondo. Ha cominciato a interessarsi di 
microcomputer ai tempi deI KlM-1 da IK. Jim possiede una 
conoscenza enciclopedica dei prodotti Commodore, come te¬ 
stimoniato da articoli, libri, lezioni e addirittura da programmi 
televisivi. In questo articolo Jim presenta la fine arte della pro¬ 
grammazione in linguaggio assembly sull’Amiga. 

Mi sembra che la programmazione in linguaggio assembly su 
Amiga sia nascosta alla vista del programmatore principiante 
medio. È nascosta in molti modi: nei file include, nelle macro e 
nelle definizioni esterne. 

Questa situazione è difficile da evitare quando si ha a che fare 
con programmi di grosse dimensioni. Questo vuol dire, per il 
principiante, che il programma che vede pubblicato è spesso un 
piccolo frammento dell’insieme. 

Quando si diventa esperti, si cominciano a usare le scorciatoie 
e le semplificazioni alla stessa maniera. Quel codice di startup 
tedioso e meticoloso verrà quindi lasciato da parte e verrà in¬ 
corporato nel programma come materiale già pronto, in scato¬ 
la. Conosceremo a memoria tre dozzine di definizioni esterne 
di frequente uso e le chiameremo spensieratamente con il loro 
nome. Metteremo insieme i nostri pezzi di codice preferiti: per 
esempio, il codice per stampare un numero decimale ci sarà 
necessario in continuazione. Scriviamolo una volta, per bene, e 
incorporiamolo quando sarà necessario nei programmi che svi¬ 
lupperemo. 

Ma il principiante si sente come se stesse procedendo nel bel 
mezzo di una storia senza avere letto i primi capitoli. È diffici¬ 
le sentirsi a proprio agio in una situazione del genere. 

Tenterò quindi di procedere lentamente in queste prime sessio¬ 
ni. Più avanti considererete alcune di queste cose tediose, ma 
ciò non vi impedirà di metterle via come parte della vostra li¬ 
breria. 

Completamente principianti? 

Il fatto di arrivare a scrivere dei programmi finiti il più veloce¬ 


mente possibile è una cosa rassicurante. Per arrivare a conse¬ 
guire questo obiettivo, sarò costretto a trattare speditamente al¬ 
cune cose che i principianti dovranno approfondire. 

Argomenti come le notazioni binaria ed esadecimale, i bus in¬ 
dirizzi e dati, i cicli di lettura ed esecuzione di un’istruzione, le 
periferiche (devices) di input/output e lo stesso sistema operati¬ 
vo verranno passati in rassegna molto velocemente, come se 
fossero perfettamente ovvii. 

Perdonatemi se vado troppo veloce su queste parti. Esistono li¬ 
bri nei quali vengono trattati in modo specifico alcuni di questi 
concetti e le letture supplementari costituiscono uno strumento 
di apprendimento molto prezioso. 

Gli strumenti necessari 

Avremo bisogno di un assembler (assemblatore), commerciale 
o di pubblico dominio. Il primo programma assembler offerto 
dalla Commodore era stato creato dalla Metacomco e funziona 
ancora bene. La maggior parte dei compilatori C vengono for¬ 
niti con un assembler che fa parte del pacchetto. Esistono an¬ 
che svariati assembler 'liberamente distribuibili’. Uno, scritto 
da Wes Howe, presenta alcuni piccoli bug e un altro, scritto da 
Charlie Gibbs, risulta completo di tutte le caratteristiche nor¬ 
mali e abbastanza esente da bug nella versione più recente 
(1989). 

Entrambi questi due programmi dovrebbero essere disponibili, 
gratis, presso un club di utenti o in una bbs o su dischi di pub¬ 
blico dominio (Fish 81 per quello di Howe e Fish 110 per quel¬ 
lo di Gibbs. Consultate un catalogo aggiornato dei dischi di 
Fred Fish per avere le versioni di più recente pubblicazione. 
NDT). Svariati assembler commerciali sono stati pubblicati 
dalla Abacus (AssemPro), da Compute! (ASM68010), dalla 
HiSoft (Devpac, vedi recensione in questo numero) e da altri 
ancora. 

A proposito dei file include, questi vengono normalmente for¬ 
niti come parte del pacchetto dell’assembler. Non preoccupate¬ 
vi di questi per il momento, ma tenete presente che sarete felici 
di averne una serie recente e a posto quando vorrete spingervi 
un poco più a fondo nella programmazione in assembly. Man 
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mano che progrediremo nel corso prenderemo in esame quelli 
che ci serviranno. 

Avremo bisogno di un ìinker. Questo sarà quasi certamente 
BLINK, lo splendido programma creato da John Toebes della 
Software Distillery. I programmi che scriveremo verranno as¬ 
semblati in file oggetto (object); questi ultimi non possono es¬ 
sere eseguiti fino a quando non vengono linkati (passati 
attraverso al Ìinker) e resi eseguibili (executable). A un primo 
esame questo potrebbe sembrare un inutile passaggio in più, 
ma impareremo ad apprezzarlo in seguito. 

Avremo bisogno di un debugger. Questo programma è l’equi¬ 
valente di quello che veniva chiamato monitor per il linguag¬ 
gio macchina sui computer Commodore a 8 bit. Il debugger 
originale per Amiga della Commodore si chiamava Wack ed è 
stato presto seguito da altri programmi commerciali, fra i quali 
spicca MetaScope. Il pacchetto AssemPro della Abacus dispo¬ 
ne di un debugger integrato e un eccellente debugger di pubbli¬ 
co dominio, al momento ancora sotto revisione, è stato 
prodotto da Jim Thibodeau e Larry La Piume. 

Avremo bisogno di manuali di riferimento. Ai principianti con¬ 
viene comperare solo un libro: The AmigaDOS Maiutai (Ban- 
tam Computer Books). Sebbene il libro sembri, a una prima 
ispezione, solamente una guida al CLI, scoprirete ben presto 
che contiene una sezione intitolata AmigaDos Developer's Ma- 
nual che racchiude praticamente tutto quello di cui avrete biso¬ 
gno per cominciare a esplorare. 

Il migliore testo di riferimento per il 68000 viene dal produtto¬ 
re del chip. Il libro The MC68000 User’s Manual’ (MC68000- 
UM/AD) è pubblicato dalla Motorola. Potreste trovare 
interessante anche un altro libro della stessa casa, chiamato 
'Family Reference Guide’ (MC68000-FR68K-D). 

Impostazione del corso 

Noterete che all’inizio del corso terrò il mio naso molto vicino 
al codice e che non userò file include o definizioni esterne. 
Questa impostazione cambierà presto, ma finché rimane mi 
aspetto che esaminiate molto attentamente il programma as- 
sembly che avete per le mani. Esistono grandi differenze fra i 
pacchetti assembler disponibili e io non posso scrivere del co¬ 
dice che soddisfi tutti. Dovrete decidere da soli i requisiti che il 
vostro pacchetto deve avere. 

Starò lontano dalle caratteristiche proprie di Amiga per un cer¬ 
to tempo. Cose come la grafica e il suono verranno più tardi. 
L’enfasi iniziale sarà concentrata sul controllo di flusso di te¬ 
sto. Comincieremo a leggere e a scrivere sullo schermo e sul 
disco. 

Mi sembra che la gestione del testo rappresenti un buon punto 
di partenza. Essa ci permetterà infatti di chiedere dei dati, man¬ 
dare messaggi e fare una serie di altre cose utili. Se siete ipno¬ 
tizzati dalla grafica, dal suono, dal blitter e dal copper, 
rassegnatevi perché non li vedrete trattati qui per ancora un 
certo tempo. 


Nozioni di base 

La memoria è organizzata in byte, come nella maggior parte 
dei microcomputer che potreste avere incontrato. Il chip 68000 
può tranquillamente leggere e memorizzare singoli byte nella 
sua memoria, utilizzando qualsiasi indirizzo valido. Esiste tut¬ 
tavia un modo più potente di accedere alla memoria: due byte 
alla volta. 

Due byte adiacenti possono essere letti o memorizzati in una 
singola mossa, purché il byte inferiore (come indirizzo) si trovi 
a un indirizzo pari. Questo paio di byte viene chiamato word e 
costituisce un sistema molto efficiente per usare i dati in me¬ 
moria. Possiamo riferirci a entrambi i byte con una singola 
istruzione alla quale dovremo fornire l’indirizzo di quello più 
in basso (inferiore). Questo indirizzo dovrà essere pari. 

Per fare un esempio, possiamo leggere (o scrivere) il contenuto 
degli indirizzi 20 e 21 in una sola azione. Ma non possiamo fa¬ 
re riferimento ai contenuti dei byte 21 e 22 in una sola volta; se 
il nostro programma tenta di compiere questa operazione, il 
computer andrà in guru segnalando un address error (errore di 
indirizzamento). 

Possiamo anche riferirci a quattro byte alla volta; questo grup¬ 
po di quattro byte viene chiamato long word. Il computer non 
può gestire una long word in una sola azione, quindi eseguirà 
due passaggi per portare a termine l’operazione. Ancora una 
volta, noi dobbiamo fornire solo l'indirizzo pari del byte infe¬ 
riore. In questo modo, una operazione su long word all’indiriz¬ 
zo 4 coinvolgerà, in pratica, i quattro byte agli indirizzi 4, 5, 6 
e 7. 

Lo schema seguente mostra le tre configurazioni di dati, più 
una quarta: gli indirizzi (address). Questi, in genere, occupano 
una long word. Dal momento che gli indirizzi sul 68000 solo 


Byte: 8 bits 


Decimai 0-255 


Word: 2 bytes 


Decimai 0-65,535 


Long Word: 4 bytes 


Decimai 04,294,967,295 


Address: effectively 3 bytes 

(Long word, with firn byte = 0) 



Decimai 0-16,777,215 


Tipi di dati del 68000 
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larghi solo 24 bit (tre byte), la parte in alto della long word non 
viene utilizzata e dovrebbe essere messa a zero. 

I registri del 68000 

Dentro ogni microprocessore si trovano zone, riservate al cal¬ 
colo e all’immagazzinamento, chiamate registri. Nel 68000 ce 
ne sono un certo numero. Faremo un breve accenno a due regi¬ 
stri speciali, quindi ci sposteremo sui registri principali, nor¬ 
malmente utilizzati per lavorare. 

II registro PC è il Program Counter, esso ci dice dove il com¬ 
puter sta lavorando, istante per istante. Il registro SR è lo Sta¬ 
tus Register, che contiene informazioni (chiamate flag) sulle 
condizioni del computer e dei suoi dati. Ne parleremo ancora, 
ma per adesso ci spostiamo nell'area principale dove si svolgo¬ 
no le operazioni: i registri dati (Data) e indirizzi (Address). 

Ci sono otto registri dati (Data Registers), chiamati da DO a 
D7. Possiamo utilizzarli in svariati modi: con byte, word o 
long word. Se usiamo un registro dati per un'operazione su by¬ 
te, per esempio, verrà modificato o esaminato solo il suo byte 
inferiore. Un’operazione su word utilizzerà solo i due byte in¬ 
feriori del registro, mentre una su long word lo userà, come 
possiamo aspettarci, tutto quanto. 

Siamo liberi di usare qualsiasi registro dati per qualsiasi scopo 
ci piaccia. È utile sapere che il registro DO è quello più spesso 
usato per memorizzare i dati che una subroutine, chiamata in 
precedenza, restituirà. Per questa ragione, faremo meglio a la¬ 
sciare DO relativamente libero. In aggiunta, il contenuto dei re¬ 
gistri DO e DI possono essere alterati dalla chiamata a una 
subroutine di sistema, così è meglio non tenervi dati che servo¬ 
no per un tempo lungo. 

Ci sono otto registri indirizzi (Address Registers), chiamati da 
A0 ad A7. Normalmente questi vengono usati con long word, 



Registri dati e indirizzi del 68000 


quindi non si possono usare per operazioni su byte. È possibile 
usarli per operazioni su word, ma, in quest’ultimo caso, il valo¬ 
re contenuto nella word viene espanso in modo da riempire 
l’intero registro indirizzi. 

Il registro A7 è speciale. Per prima cosa è un registro 'doppio’: 
esiste infatti una seconda copia del registro A7 che non vedre¬ 
mo mai e della quale non ci preoccuperemo fino a quando non 
arriveremo a trattare roba pesante e potente come il modo su¬ 
pervisore (supervisor mode). 

In secondo luogo, il registro A7 è il puntatore allo stack princi¬ 
pale del nostro programma. Possiamo utilizzarlo, ma trattiamo¬ 
lo con rispetto. Se lo lasciamo stare, saprà badare a sè stesso 
senza problemi. 

Il registro A6 ha un significato speciale su Amiga. Deve essere 
utilizzato come puntatore di libreria (library pointer) tutte le 
volte che si chiama una libreria Amiga (e questo avverrà spes¬ 
sissimo). Riservate il registro A6 per questo utilizzo; avremo a 
che farci quanto prima. 

Gli altri registri da A0 ad A5 possono essere utilizzati libera¬ 
mente in qualsiasi maniera ci piaccia. Teniamo a mente che il 
contenuto dei registri A0 e Al può essere modificato dalle su¬ 
broutine di sistema, quindi tenteremo di tenerli abbastanza pu¬ 
liti. 

Se avete programmato sui computer Commodore a 8 bit, potre¬ 
te trovare utile il fatto di pensare ai registri indirizzi in termini 
del funzionamento della pagina zero sul 6502. Dovremo sicu¬ 
ramente utilizzarli quando avremo a che fare con l’indirizza- 
mento indiretto (ma non per questa volta). 

Man mano che cominceremo a esplorare le librerie incorporate 
in Amiga, scopriremo che le subroutine si fanno passare gli ar¬ 
gomenti nei registri dati e indirizzi con numerazione bassa. 
Tenderemo quindi a mettere i dati e gli indirizzi, che ci servo¬ 
no per un certo tempo, nei registri a numerazione alta, in modo 
da ridurre i passaggi inutili. 

Un primo programma 

Caspita, tutta questa teoria e non abbiamo ancora messo le ma¬ 
ni su qualcosa di pratico. Prepariamo allora un progetto e occu¬ 
piamoci di codificarlo. Mi sembra che il programma per 
principianti più diffuso (negli altri linguaggi) sia quello che 
stampa sul video 'Hello World!'. 

Questo programma girerà solo da CLI, per risparmiarci tutte le 
complicazioni richieste per un programma che giri anche da 
Workbench. Lo chiameremo TEST, così quando scriveremo il 
comando TEST nel CLI o nella Shell, il programma stamperà 
Hello, World! sullo schermo. 

Vedremo che cosa bisogna fare in un approccio che parte dalla 
base e va verso i livelli superiori, cominciando con il lavoro 
che dobbiamo fare. Per stampare un messaggio useremo il co¬ 
mando Write contenuto nella libreria del DOS. 
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Il comando Write 

La sintassi del comando Write è come segue: 


returnedLength = Write(file,buffer,length) 

DO DI D2 D3 

DI - file = file handle 

D2 - buffer = puntatore al testo da stampare 
D3 - length = intero, lunghezza del testo 
DO - returnedLength = intero, conferma della 
lunghezza del testo 


Locazione: -$30 nella jump table del DOS 


Imparerete a leggere questo tipo di sintassi molto velocemente. 
Dando un’occhiata all’informazione contenuta, vediamo che 
buffer e length sembrano abbastanza semplici da capire: quello 
è il nostro messaggio. Il valore returnedLength conferma che il 
nostro output è stato eseguito con successo. 

La locazione data è la posizione del comando Write all’interno 
della tabella di salto (jump table) della libreria. Entreremo nei 
dettagli di questo in seguito. C'è rimasto solo un pezzetto di in¬ 
formazione che non abbiamo ancora visto: cosa diavolo è un 
file handle? 

Un file handle è un identificatore che dice al sistema quale ca¬ 
nale di input o di output utilizzare. Questo sta bene, ma come 
facciamo a procurarci questo numero? Non è così semplice co¬ 
me il numero di periferica che usavamo sul Commodore 64. 

Come ci procuriamo il file handle? Se apriamo un file, lo otte¬ 
niamo automaticamente. Ma adesso abbiamo bisogno di otte¬ 
nere il file handle del nostro canale di output che esiste già (il 
CLI dal quale abbiamo eseguito TEST). Nessun problema: 
usiamo Output. 

La sintassi di Output è: 


mr 


-$3C 

Output 


-$30 

Write 


DosBase pointer 



A6. > $0 



get pointer 



by calling 



OpenLibrary 




La jump table della DOS library... da qualche 
parte in memoria 


Librerie e jump table 


La libreria del DOS non risiede in alcuna zona fissa della 
RAM. Probabilmente nel vostro computer sarà in una posizio¬ 
ne diversa da quella occupata adesso nel mio. In teoria, potreb¬ 
be addirittura non risiedere affatto nella RAM, nel qual caso 
dovrà esservi caricata. Ancora in teoria, potrebbe addirittura 
essersi spostata dall’ultima volta che l’abbiamo usata. 


Dobbiamo quindi trovare la libreria, caricarla in memoria se 
questo risulta necessario e quindi inchiodarla in modo che non 
si sposti mentre la stiamo usando. Tutte queste operazioni sono 
svolte da un unico comando: OpenLibrary. Più tardi, quando 
non avremo più bisogno della libreria, dovremo liberarla. Que- 
st’ultima operazione è svolta dal comando CloseLibrary. 


file = output o Questa è la sintassi del comando OpenLibrary: 

DO 


DO - file = file handle 


LibPtr = OpenLibrary(LibName,Version) 
DO Al DO 


Locazione: -$3C nella jump table del DOS 

Il comando Write ci chiedeva di fornire tre parti di informazio¬ 
ne. Output non ha bisogno di parametri; basta chiamarlo per ri¬ 
cevere il valore del nostro file handle nel registro DO. 

Il nostro compito programmatorio adesso sembra più chiaro. 
Chiamiamo Output per avere il file handle del nostro canale di 
output (lo schermo CLI, a meno che non sia stata usata la redi¬ 
rezione nel lanciare TEST); usiamo quel file handle, più l’indi¬ 
rizzo del nostro messaggio 'Hello World!’ e la sua lunghezza, 
chiamiamo Write e via che va. 

Ma c’è un piccolo problema. Le due routine di cui abbiamo bi¬ 
sogno, Output e Write, sono locate in -$3C e -$30 nella jump 
table della libreria del DOS. Ma dove diavolo è questa libreria? 


Al - LibName = puntatore alla stringa che 
indica il nome della libreria 
DO - Version = numero di versione richiesta, 
zero per qualsiasi versione 
DO - LibPtr = puntatore alla libreria, zero 
se non è stata trovata 

Locazione: -$228 nella jump table dell'Exec 

Per trovare, quindi, il puntatore alla base della libreria del 
DOS, prepariamo una stringa con il nome della libreria che ci 
serve, dos.library, seguito da un byte a zero per segnalarne la 
fine. Mettiamo l’indirizzo di questa stringa nel registro Al, uno 
zero in DO e quindi chiamiamo la OpenLibrary. Quando la 
funzione restituisce il controllo, il registro DO contiene uno ze¬ 
ro nel caso che la libreria richiesta non sia stata trovata (abbia- 
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-$228 

OpenLibrary 


-$19E 

CloseLibrary 


ExecBase pointer 



A6— -> $0 



get pointer 



value from 



location 4 




La jump table della Exec library... da qualche 
parte in memoria 

mo probabilmente sbagliato a scriverne il nome), oppure l’indi¬ 
rizzo della libreria del DOS, che è proprio ciò che volevamo. 

Potreste avere notato, a questo punto, un apparente paradosso: 
come facciamo a trovare la libreria deH’Exec? Abbiate fiducia: 
ci arriveremo senza fatica. Per il momento, seguite il flusso 
centrale degli eventi. 

Una volta trovato il puntatore alla libreria del DOS, possiamo 
trovare facilmente i punti di ingresso nella jump table per le 
funzioni Output e Write utilizzando gli offset da quel punto. 
Notate che gli offset sono rappresentati da numeri negativi; 
contiamo dal puntatore in giù per raggiungere la casella appro¬ 
data nella jump table. Di conseguenza, se il puntatore della li¬ 
breria del DOS contiene l’indirizzo SC04C70, il salto per la 
subroutine Output verrà effettuato $3C byte più in basso , il che 
corrisponde all’indirizzo SC04C34. 

Non preoccupatevi troppo dei numeri; il computer si farà cari¬ 
co dei calcoli aritmetici al nostro posto. A seconda del pacchet¬ 
to di debug che userete, potrete trovare utile il fatto di sapere 
che i valori negativi vengono memorizzati dal computer secon¬ 
do il complemento a due, così che -$3C potrebbe apparire co¬ 
me $FFFFFFC4 quando utilizzate il vostro debugger. 

Ricapitoliamo la situazione 

Può risultare utile dare un’occhiata al nostro programma così 
come si è delineato fino a questo punto. 

1. Trovare la libreria del DOS chiamando 

OpenLibrary 

2. Ottenere il file handle chiamando Output 

3. Spedire il messaggio chiamando Write 

4. Liberare la libreria del DOS chiamando 

CloseLibrary 


Quest’ultima funzione non è ancora stata ben documentata, 
quindi eccone la sintassi: 

CloseLibrary(libPtr) 

Al 

Al - libPtr - puntatore alla libreria che 
vogliamo chiudere 

Locazione: -$19E nella libreria dell'Exec 

L’unico pezzo mancante adesso è come facciamo a trovare la 
libreria deH’Exec? Risposta: facile, il suo indirizzo è sempre 
contenuto nella long word che comincia all’indirizzo 4. 

Dentro il codice 

Prima, una veloce nota sul fatto che dobbiamo mettere due 
stringhe in memoria. Una è il nome della libreria del DOS se¬ 
guita da uno zero binario. L’altra è il nostro messaggio. Vedia¬ 
mo in anticipo queste due linee di istruzione; non ne avremo 
veramente bisogno prima della fine del nostro programma. 

DosName dc.b 'dos.library',0 
Message dc.b 'Hello, World!',$0a 

Le etichette DosName e Message contrassegnano l’indirizzo al 
quale iniziano le rispettive stringhe. 11 comando dell’assembler 
DC.B sta per define Constant, byte (definizione di costante, by¬ 
te) e significa: adesso viene un gruppo di byte che devono es¬ 
sere messi nella memoria. Questi byte possono essere caratteri 
come dos.library (fate attenzione alle minuscole e alle maiu¬ 
scole) o valori come lo zero binario che serve a terminare la 
prima stringa. La seconda stringa non ha bisogno di terminare 
con uno zero; ne conteremo i caratteri e diremo a Write quanti 
mandante. 

Non mettete ancora queste linee nel vostro programma. Le ab¬ 
biamo viste adesso così che possiate sapere cosa sono quando 
verrà il loro turno. 

Invadiamo l’Exec 

L’indirizzo della libreria dell’Exec è memorizzato all'indirizzo 
4 (long word). Quando usiamo una libreria di Amiga, prima 
dobbiamo mettere il puntatore alla libreria nel registro A6. 
Facciamolo. 

MOVE.L $4 , A6 

Muovi, long word, il contenuto dell’indirizzo 4 nel registro A6. 
Adesso il puntatore all’Exec è in A6. 

Prima di chiamare OpenLibrary dobbiamo mettere il puntatore 
al nome della libreria da aprire in AL Una buona strada per 
mettere un indirizzo in un registro consiste nell’utilizzare il co¬ 
mando LEA (Load Effective Address, carica l’indirizzo effetti¬ 
vo). Potremmo scrivere LEA DosName, Al e questo 
funzionerebbe. Ma saremo più specifici e scriveremo: 

LEA DosName(PC),Al 
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La notazione PC significa questo: trova l’indirizzo calcolando¬ 
ne l’offset da questo punto del programma. Sarà all’incirca cin¬ 
quanta byte più avanti, ma il computer si prenderà cura di 
questi dettagli. Specificando PC risparmieremo un po’ di me¬ 
moria, sebbene il programma funzionerebbe comunque venisse 
calcolato l’indirizzo della stringa corrispondente all’etichetta 
DosName. 

Adesso dobbiamo occuparci della versione della libreria. Ci va 
bene qualsiasi revisione potremmo trovare, quindi useremo 
uno zero. Possiamo mettere il valore zero nel registro DO in 
molti modi diversi. Per esempio CLR.L DO (clear long word, 
pulisci long word) andrebbe bene. Noi useremo il comando 
MOVEQ (move quick, muovi velocemente). 

MOVEQ #0, DO 

Adesso siamo pronti a chiamare la funzione della libreria. Il re¬ 
gistro A6 contiene il puntatore alla libreria. JSR (A6) chiame¬ 
rebbe una subroutine (Jump Subroutine) che inizia a 
quell’indirizzo, ma questo sarebbe folle; salteremmo compieta- 
mente la jump table! Notate l’uso delle parentesi per segnalare 
un indirizzo indiretto; non saltiamo in A6, ma all’indirizzo 
contenuto in A6. Ma non vogliamo saltare là; vogliamo invece 
usare l’offset di -$228 da quell’indirizzo per chiamare la Open- 
Library. Ecco quindi cosa scriviamo: 

JSR -S228(A6) 

Questa istruzione chiamerà la funzione OpenLibrary contenuta 
nella libreria dell’Exec. Ma per carità, non dimenticate A6, che 
punta alla libreria. Omettetelo per distrazione e salterete nell'o¬ 
blio. Il sistema potrebbe andare in crash così velocemente da 
non vedere neanche il guru. 

Quando la routine OpenLibrary ritorna, il registro DO dovrebbe 
contenere il puntatore alla libreria del DOS. In caso contrario, 
avrete probabilmente sbagliato nello scrivere il nome della li¬ 
breria, o dimenticato lo zero binario alla fine. Controlliamo in 
ogni caso, mentre spostiamo il puntatore alla libreria in A6: 

MOVE . L DO, A6 

L’indirizzo che avevamo ottenuto si trova adesso in A6. Ma 
cosa succede se è zero? In questo caso, meglio saltare tutto il 
resto del programma e uscire. Dopo quest’ultima istruzione, il 
flag Z (zero) sarà settato (alto, a uno) se tutti i bit spostati erano 
a zero. Così possiamo controllare con l’istruzione BEQ (branch 
equal, salta se uguale). Sappiamo che questo salto sarà abba¬ 
stanza corto, quindi identifichiamolo come short (corto): 

BEQ.S Exit 

Breve salto se uguale (a zero) all’etichetta Exit, una linea di 
istruzione che vedremo fra poco. A questo punto mettiamo il 
resto del nostro lavoro in una subroutine e chiamiamolo con 
BSR (branch subroutine, salta alla subroutine). Ancora una 
volta, il salto sarà breve: 

BSR.S Main 


Perchè abbiamo chiamato questa subroutine con BSR (branch), 
quando abbiamo fatto una chiamata poco prima utilizzando 
JSR (jump)? E un fatto di vicinanza. Sappiamo che la subrouti¬ 
ne Main si troverà nelle vicinanze, quindi l’istruzione Branch, 
più compatta della Jump, ci farà risparmiare della memoria. Le 
chiamate di sistema non possono essere fatte utilizzando l’i¬ 
struzione BSR per diverse ragioni, la più semplice delle quali 
consiste nel fatto che la libreria si troverà probabilmente troppo 
lontana per essere raggiunta con un branch. 

Quando il nostro compito principale è completato, faremo ri¬ 
torno in questo punto, chiuderemo la libreria del DOS e uscire¬ 
mo. Il nostro puntatore alla libreria del DOS si dovrebbe 
ancora trovare in A6. Ricordandoci che la CloseLibrary vuole 
vedere questo puntatore in A1, scriveremo: 

MOVE. L A6,A1 

Adesso mettiamo di nuovo il puntatore alla libreria dell’Exec 
nel registro A6: 

MOVE.L $4,A6 

Siamo pronti a chiamare la CloseLibrary, contenuta nell’Exec 
all’offset -$19E: 

JSR -$19E(A6) 

Exit : 

RTS 

Il guscio esterno è pronto. Adesso possiamo concentrarci sul 
cuore che dobbiamo creare. 

Breve interludio 

Il codice che abbiamo appena visto prepara tutte le cose in mo¬ 
do da permetterci di svolgere il nostro compito principale. Per 
compiti simili potremo utilizzare lo stesso codice introduttivo, 
per preparare la base di lavoro. 

Questo tipo di approccio viene chiamato startup-code (codice 
di inizializzazione). Lo usiamo (o ne usiamo una versione un 
po' più complessa) sempre, praticamente per tutto quello che 
facciamo. Dopo un po’, tutto questo diventa noioso. A questo 
punto potremo fare una qualsiasi delle seguenti cose: metterlo 
in un file e portarlo dentro al nostro programma tramite l’istru¬ 
zione include', metterlo in una macro e quindi farne un pezzo di 
programma in scatola; oppure assemblarlo e portarlo dentro al 
programma con il linker, quando ci serve. 

Dopo avere scritto qualche dozzina di programmi, non vorrete 
o non avrete più bisogno di occuparvi del codice di startup nel¬ 
la maggior parte dei casi. Vi tufferete direttamente nel cuore 
del programma e assumerete che il codice di startup in scatola 
funzioni correttamente. 

Noi, comunque, daremo un’occhiata a questo codice per le pri¬ 
me volte. Di tanto in tanto è bello potere mettere le mani in 
questa zona e personalizzarla per i propri bisogni. 
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Il cuore del programma 

Il codice di startup chiama questa parte del programma come 
una subroutine (con un BSR). Il registro A6 contiene il punta¬ 
tore alla libreria del DOS. Siamo pronti a procedere. Per prima 
cosa chiamiamo la funzione Output per ottenere il nostro file 
handle. Non c’è bisogno di preparare alcun parametro: 

Main : 

JSR -$3C(A6) 

Il file handle si trova adesso in DO. Ne abbiamo bisogno in DI 
per la funzione Wrìte : 

MOVE . L DO, DI 

Adesso dobbiamo mettere Findirizzo di ’Hello, World!’ in D2. 
Il comando LEA (Load Effective Address) funziona solo con i 
registri indirizzi, quindi effettueremo l'operazione in due pas¬ 
saggi: 

LEA Message(PC),AO 

MOVE . L AO, D2 

Conteremo i caratteri contenuti nella stringa-messaggio ma¬ 
nualmente, per questa volta. Includendo il punto esclamativo e 
il seguente carattere di newline (nuova linea, $0A), abbiamo 
14 caratteri, quindi carichiamo velocemente questo numero, 
scrivendo: 

MOVEQ #14,D3 
JSR -$30(A6) 

Abbiamo fatto la nostra chiamata a Wrìte e il nostro compito è 
quindi finito. Ritorniamo al codice di startup, scrivendo: 

RTS 

Infine, ecco le due stringhe che abbiamo menzionato prima: 

DosName dc.b 'dos.library',0 
Message dc.b 'Hello, World!' , $0a 

Questo è tutto quello che serve. Rivediamo adesso il program¬ 
ma nel suo insieme, con un po’ di istruzioni equate per sosti¬ 
tuire gli offset delle jump table con qualcosa di più leggibile e 
con l’aggiunta di un paio di commenti. 

La maggior parte degli assembler richiede che le etichette 
(chiamate a volte anche simboli) siano allineate col margine si¬ 
nistro. Le linee senza etichetta dovrebbero essere indentate sul¬ 
la destra. Nel listato che segue, questa convenzione viene 
rispettata. Le regole che riguardano le linee di commento, che 
cominciano con un punto e virgola, variano a seconda dell’as- 
sembler; io le ho indentate per rendere migliore la leggibilità 
dell’insieme. 

; programma Hello 

; codice di startup adatto solo al CLI 


LVOOpenLibrary equ -$228 
LVOCloseLibrary equ -$19E 

; LVO significa Library Vector Offset 


MOVE.L 

$4, A6 

; base dell'Exec 

LEA 

DosName(PC),Al 

; puntatore a nome dell; 

; libreria del DOS 

MOVEQ 

#0, DO 

; qualsiasi versione 

JSR 

LVOOpenLibrary(A6) 

MOVE.L 

DO, A6 

; puntatore a base DOS 

BEQ.S 

Exit 

; zero, esci 

BSR. S 

Main 

; fai il tuo lavoro 

MOVE.L 

A6, Al 

; puntatore a base DOS 

MOVE.L 

$4, A6 

; puntatore a base Exec 

JSR 

_LVOCloseLibrary(A6) 


Exit : 
RTS 


Main: 

; parte principale 
; equate per la libreria del DOS 


_LVOOutput 

equ 

-$3C 

_LVOWrite 

equ 

-$30 

JSR 

_LVOOutput(A6) 

; prendi output handle 

MOVE.L 

DO, DI 

; metti handle in DI 

LEA 

Message(PC),AO 

; indirizzo messaggio 

MOVE.L 

AO, D2 

; mettilo in D2 

MOVEQ 

#14,D3 

; lunghezza messaggio 

JSR 

_LVOWrite(A6) 

; spedisci messaggio 

RTS 



DosName 

dc.b 'dos.library',0 

Message 

dc.b 'Hello, 

World!',$0a 

end 




Mettiamo tutto insieme 

Digitate questo listato usando il vostro editor preferito e salva¬ 
telo usando il nome TEST.ASM o TEST.S. Fate molta atten¬ 
zione alle maiuscole e alle minuscole quando scrivete le 
etichette o i nomi delle librerie e delle funzioni. 

Se avete il file Amiga.lib, che si trova sul disco degli sviluppa¬ 
tori o negli assemblatori commerciali, potreste cambiare le li¬ 
nee equ in qualcosa di più conveniente. Potreste usare un xref 
(external reference, riferimento esterno) al posto di equ e la¬ 
sciare al linker il compito di trovare il giusto valore di offset. 
La prossima volta vedremo come fare. Per il momento, il pro¬ 
gramma stampato qui è completo e non richiede supporto 
esterno. 


; equate per la libreria dell'Exec 


Continua a pagina 56 
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Breakpoint 


Quinta parte della serie di articoli sul debugging 


di Victor A. Wagner Copyright (c)1989 Victor A. Wagner, Jr. 


Vie Wagner iniziò ad avere a che fare con i calcolatori ne! 
1965 quando divenne parte di un gruppo di studio della US Air 
Force sulla simulazione digitale del volo. Tornato un civile nel 
1966, ha lavorato in quell’epoca, principalmente con costrut¬ 
tori di minicomputer, nel campo del software per sistemi in 
tempo reale. Nei giorni feriali dalle 8 alle 5, Vie cura la consu¬ 
lenza tecnica telefonica per la Computer Automation Ine. e la 
manutenzione del software di tre sistemi in tempo reale. Alla 
sera e nei fine settimana, trascorre il suo tempo conversando 
con Taarna (il suo Amiga 1000), scrivendo programmi e colle¬ 
gandosi ad AmigaForum. Vie è, inoltre, un’autorità ricono¬ 
sciuta per quanto riguarda il famoso programma di debugging 
MetaScope prodotto dalla Metadigm Ine. 

In quest’ultima puntata daremo un’occhiata agli ultimi due de- 
bugger disponibili sul mercato dei prodotti commerciali per 
Amiga. Questi due programmi sono presenti nell’arena dei de- 
bugger Amiga sin dai primi tempi e l’interfaccia utente di uno 
differisce da quella dell’altro nella massima misura possibile. 
DB, prodotto dalla Manx Software Systems, usa principalmen¬ 
te un’interfaccia testuale; MetaScope, prodotto dalla Meta¬ 
digm, è completamente immerso in Intuition (menu, gadget, 
punta e seleziona). Entrambi sono ampiamente equivalenti per 
quanto riguarda le prestazioni. 

Prima di continuare, dovrei far presente che ho usato MetaSco¬ 
pe fin da prima che fosse ufficialmente lanciato sul mercato e 
che nutro interessi finanziari ed emotivi nel suo successo. Co¬ 
nosco l’autore da più di dieci anni e durante tutto l’arco di tem¬ 
po occupato dalla progettazione e dall’implementazione di 
MetaScope, abbiamo passato parecchi intervalli del pranzo in¬ 
gozzandoci di pizza (l’unico vero cibo per un programmatore) 
e discutendone le caratteristiche e le potenzialità. Ho effettuato 
prove molto severe e accurate di MetaScope e sono l’autore del 
testo dimostrativo presente nell’edizione attuale. Non sorpren¬ 
de, quindi, il fatto che MetaScope segua (fino a un certo punto) 
i miei pregiudizi per quanto riguarda le tecniche di debugging, 
sebbene alcune sue caratteristiche mi portino a distrarmi. Mi 
sforzerò di darne un’immagine che sia il meno influenzata pos¬ 
sibile. 

Okay, diamo un’occhiata all’aspetto esterno dei debugger pri¬ 
ma di farci irretire dalle loro caratteristiche interne. 


MetaScope 81336 -rwed 17-Jan-89 11:32:06 

db 60360 -rwed 18-Jun-87 17:30:48 

Le versioni dei miei programmi sono: 

Aztec C Debugger - Version 3.4b - 6-16-87 
MetaScope: The Debugger (Version 1.23) 

Questa versione di MetaScope è una versione preliminare ’be- 
ta’ e al momento è compatibile con i sorgenti scritti per il com¬ 
pilatore Lattice. Per il giorno in cui leggerete questo articolo, 
dovrebbe essere compatibile anche con quelli scritti per il com¬ 
pilatore Manx. 

Come possiamo vedere, MetaScope è all’incirca del 35 per 
cento più grande sul disco. In memoria, i programmi presenta¬ 
no queste dimensioni: 


MetaScope: 



DB: 



indirizzo 

Hex 

Dee 

indirizzo 

Hex 

Dee 

0267D8 

D4 

212 

86EBF8 

4 

4 

87A5D0 

3398 

13208 

87A5D0 

2D4C 

11596 

8CDAC8 

103C0 

66496 

87D328 

31B4 

12724 


===== 

===== 

8921B0 

32D0 

13008 


1382C 

79916 

895B70 

B14 

2836 




89E8D0 

22C8 

8904 




8B80C0 

24CC 

9420 




8BA598 

2028 

8232 





104A4 

66724 


MetaScope è all’incirca del 20 per cento più grande quando si 
trova in memoria. Ricordate che Amiga effettua il caricamento 
in ordine sparso, quindi gli indirizzi hanno poco significato. 

L’altra differenza fisica risiede nei manuali. Il manuale di DB è 
di 42 pagine, provvisto di foratura a tre buchi e fornito insieme 
al manuale del compilatore nell’unico raccoglitore ad anelli. Il 
manuale di MetaScope è di 35 pagine sotto forma di libretto a 
sè stante. Nessuno dei due è fornito di indice, ma entrambi 
hanno una tavola dei contenuti e sono scritti secondo lo stile 
che contraddistingue i manuali di programmi per computer: so- 
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migliano più a dei dizionari piuttosto che a dei racconti. 

DB ha molti comandi relativi ad Amiga (cominciano tutti per 
a) per i quali non esistono controparti in MS. Molte (magari 

Considerando le notevoli difficoltà nelle quali mi sono imbat¬ 
tuto nello scrivere di debugging in generale, non posso che im¬ 
medesimarmi con gli autori di questi due manuali. Ci sono un 
gran numero di informazioni da impartire al lettore e la mag¬ 
gior parte di queste non sono correlate o omogenee. Tutti i de- 
bugger assomigliano a una collezione di cose che i 
programmatori hanno trovato essere loro utili lungo il corso di 
molti anni. Quanto detto non va preso come una critica negati¬ 
va dei due manuali, ma piuttosto come spiegazione del fatto 
che sono un po’ sconnessi. 

tutte) le liste dell'Exec possono essere visualizzate: devices, in- 
terrupts, libraries, ports, resources e tasks. 

Il comando an è particolarmente utile, specialmente se stiamo 
effettuando il debugging di più task. Quando DB viene lancia¬ 
to, apre una finestra per lo scambio di comunicazioni. Con 
questo comando viene aperta un’altra di queste finestre e si 
possono quindi seguire due programmi contemporaneamente. 
Naturalmente bisogna usare il comando a1 per catturare il pros¬ 
simo programma che si fa partire. 

Una consultazione anche solo saltuaria dei manuali farà emer¬ 
gere chiaramente le grosse differenze che esistono nell’inter¬ 
faccia utente dei due programmi. Quella di DB è strettamente 
testuale, come quella di molti debugger che l'hanno preceduto. 
DB parte con una finestra, un messaggio e il cursore. Il con¬ 
trollo su un programma viene acquistato mediante l’uso del co¬ 
mando al o r/L. 4 Questo mette in atto alcuni meccanismi di 
intercettazione nell’AmigaDOS e assume il controllo del pros¬ 
simo programma lanciato da CLI o da Workbench, stampando 
il contenuto dei registri e attendendo ulteriori istruzioni. 

DB dispone di breakpoint che controllano il valore di locazioni 
di memoria e che fermano il programma quando queste loca¬ 
zioni di memoria assumono un valore uguale (o NOT) a quello 
specificato. Il tempo che DB impiega a rendersi conto che il 
valore di questa locazione di memoria è cambiata dipende dal 
modo di funzionamento in cui DB si trova in quel momento. 

Se stiamo procedendo un passo alla volta (single-stepping), il 
rilevamento è immediato; se no, questi breakpoint associati a 
cambiamenti in memoria vengono esaminati all’ingresso e al¬ 
l’uscita di ogni funzione. DB può anche effettuare un’opera¬ 
zione di hash o di checksum su una determinata zona di 

MetaScope. d’altro canto, apre una cosiddetta status window 
(finestra di stato) e poi attende istruzioni. Non appare nemme¬ 
no un posto dove scrivere qualcosa. MetaScope (d’ora in poi 
abbreviato in MS), comunque, è un programma molto ’Ami- 
ghizzato’; sulla sua finestra si trovano svariati menu, uno dei 
quali ci permette di caricare un programma. MetaScope per¬ 
mette inoltre di fornire il nome del programma da debuggare, 
completo della sua serie di argomenti, sulla stessa linea di in¬ 
vocazione di MS: 

memoria e mantenere un controllo periodico come quello de¬ 
scritto sopra. Nel manuale viene dato un avvertimento esplicito 
a non impiegare questo tipo di controllo sui primi 256 byte del¬ 
la memoria perché questo rallenterebbe la capacità di eseguire 
una singola istruzione alla volta. Esiste un comando speciale 
per tenere sotto controllo i primi 256 byte della memoria. 

DB possiede una caratteristica che, sono sicuro, ogni program¬ 
matore ha desiderato a un certo punto della sua attività. Possia¬ 
mo infatti fornire l’indirizzo di una funzione che verrà 

!>MetaScope dfO:projs/aargh -a -b -c 

chiamata ogni volta che DB riacquista il controllo. Se la fun¬ 
zione restituisce zero, allora è come se non fosse successo nul- 

L’esempio sopra riportato è stato preso da manuale di MS. DB, 
invece, ha un file di default che viene letto quando il program¬ 
ma viene invocato. Se questo file contiene la singola istruzione 
al (Amiga, carica con simboli) allora le due istruzioni seguenti 
produrranno il medesimo effetto precedentemente visto per 
MS: 

la. Ma se il valore restituito è diverso da zero, il programma 
viene interrotto e viene visualizzato un messaggio contenente il 
numero in questione. 

Con DB possiamo usare due breakpoint temporanei, sia da soli 
sia insieme ai normali breakpoint contenuti nell’apposita lista. 

l>db 

l>df0 : pròjs/aargh -a -b -c 

Facendo eseguire una serie di comandi al raggiungimento di un 
breakpoint, si possono visualizzare determinate locazioni di 
memoria quando viene sospesa l’esecuzione del programma. 

Anziché spiegarvi passo per passo cosa possono fare entrambi i 
debugger, farò un elenco delle cose che l’uno può fare e l’altro 
no. 

Nel manuale di DB almeno sei pagine sono interamente riser¬ 
vate al comando print. Quest’ultimo ci permette di formattare i 
dati in tutti i modi possibili e immaginabili. I formati sembrano 

Per prima cosa, dovrei far notare che entrambi sono dotati di 
notevoli capacità di elaborare espressioni. Il manuale di MS 
dedica 2 pagine e mezza per dettagliare le proprie (assomiglia¬ 
no molto a quelle del C). Quello di DB vi dedica circa tre pagi¬ 
ne. Non scommetterei una lira sul fatto che uno sia più potente 
dell’altro. 

quasi essere un’estensione di quelli di printfO e sono altrettanto 
criptici. 

Ci sono comandi per allocare (forse per i patch), confrontare, 
riempire e spostare la memoria e si possono salvare fino a 26 
macro (una per ogni lettera sulla tastiera). Quest’ultima caratte- 

Okay, addentriamoci nei dettagli. Passeremo in rassegna i co¬ 
mandi di DB approssimativamente in ordine alfabetico e fare¬ 
mo dei commenti sulle cose mancanti in MS. 

ristica dovrebbe farci risparmiare un bel po’ di tempo, in quan¬ 
to l’operazione di richiamare una macro dalla memoria sarà 
sempre molto più veloce di dovere digitare l’equivalente da ta¬ 
stiera. 
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L’input/output può essere redirezionato in modo da leggere i 
comandi da un file e da mandare l’output in un altro file anzi¬ 
ché sul video. Risulta particolarmente utile la capacità di man¬ 
dare solo i comandi in un file, in modo da poterli rileggere in 
un secondo tempo e ricostruire le operazioni che si stanno fa¬ 
cendo ora. 

La prima cosa che si nota, cominciando a giocherellare con 
MS, è che non sembra esserci un limite al numero di finestre di 
output che si possono aprire. Sebbene questo sia fondamental¬ 
mente vero (dal momento che ogni finestra occupa un poco di 
memoria, esiste comunque un limite stabilito dalla quantità di 
memoria disponibile), l’utilità di avere più finestre di tipo bre¬ 
ak, hunk, status o symbol è limitata. 

Avere più finestre di tipo memory , invece, cambia il proprio 
modo di vedere il debugging. Se eravate abituati a dare qual¬ 
che tipo di comando per visualizzare della memoria ogni volta 
che veniva raggiunto un breakpoint, questo diventa compieta- 
mente inutile in MS (oltre che impossibile). Basta semplice- 
mente aprire un finestra sulla memoria da controllare e MS la 
visualizzerà. Prima che possiate dire "Aspetta un momento, io 
uso i miei comandi per visualizzare qualcosa basandomi sul 
contenuto di un registro o di una variabile", devo segnalare che 
MS permette di usare al massimo la sua capacità di elaborare 
espressioni, proprio per determinare l’indirizzo di partenza di 
quella finestra. L'espressione può essere sia statica (fissata al 
momento del suo inserimento), sia dinamica (determinata ogni 
volta che il contenuto della finestra deve essere visualizzato). 
Espressioni che risultano particolarmente utili sono: pc - il pro¬ 
gram counter attuale, utile per vedere dove si trova in questo 
momento il programma e sp - lo stack pointer attuale, per pote¬ 
re esaminare tutti gli argomenti di una funzione e altro ancora. 

Naturalmente, vorremo che queste espressioni siano 'dinami¬ 
che’ in modo da poter vedere la memoria man mano che i regi¬ 
stri cambiano. L’uso della parola 'dinamico’ potrebbe indurre 
in un piccolo errore, dal momento che le espressioni che con¬ 
tengono registri vengono calcolate solo quando MS ha il con¬ 
trollo del programma. Sebbene questo ci permetta lo stesso di 
guardare la memoria a cui si riferiscono i registri, non spreca 
tanto tempo a ricostruire il display delle varie zone di memoria 
mentre il nostro programma sta girando. 

Vi sento chiedere 'Ma allora sicuramente MS non visualizza i 
cambiamenti che avvengono in memoria mentre il mio pro¬ 
gramma sta girando e mentre MS non ha il controllo delle co¬ 
se’. Ebbene, questa potrebbe essere la maggiore differenza fra 
MS e i debugger che abbiamo visto finora. 

MS aggiorna l’output delle sue finestre sulla memoria circa 
dieci volte al secondo, indipendentemente dal fatto che il pro¬ 
gramma stia girando o meno. Questo significa che possiamo 
vedere le variabili delle coordinate x e y del mouse, in una 
struttura Window, cambiare, mentre noi muoviamo il mouse in 
giro. 

Tutte le finestre di MS sono dotate di barre per lo scrolling e di 
gadget di dimensionamento in modo da poter cambiare la 
quantità di dati visualizzati o scrollare quà e là. Possiamo inol¬ 


tre selezionare indirizzi da esaminare o da usare nei breakpoint 
semplicemente puntandoli e selezionandoli con il mouse. 

Sui breakpoint permanenti possiamo anche mettere delle con¬ 
dizioni. Queste sono espressioni che vengono valutate ogni 
volta che il breakpoint associato viene raggiunto. Se l’espres¬ 
sione risulta vera (diversa da zero), allora il contatore associato 
al breakpoint viene incrementato e, se l'appropriato valore del 
contatore è stato raggiunto, il programma viene sospeso. Que¬ 
sto significa che MS può produrre breakpoint conte: 'fermati la 
terza volta che passi di qui e che trovi il contenuto del registro 
DO uguale all’inizio del buffer di input’. 

MS è dotato di un comando freeze (congelare) che si può ap¬ 
plicare a entrambe le finestre di status e di memoria. Questo 
mantiene il contenuto di tali finestre costante per una compara¬ 
zione che si vuole fare più avanti con il contenuto delle stesse 
finestre in un altro punto del programma. Questo comando 
può, inoltre, risistemare a piacimento la macchina nelle stesse 
condizioni contenute nelle finestre congelate. Ciò significa che 
possiamo salvare le condizioni della macchina (congelando le 
finestre appropriate) e poi ripristinarle più tardi quando voglia¬ 
mo tornare indietro e provare ancora. 

Possiamo fare registrare automaticamente a MS tutte le sue 
mosse in un file (su disco o su stampante). Possiamo anche 
mandare l'intero contenuto di una finestra in questo file. 

Con MS possiamo dare i nomi che vogliamo a tutte le nostre 
numerose finestre, per esempio 'Dove siamo adesso’ (per una 
finestra con indirizzo di base dinamico basato sul contenuto di 
pc) oppure 'Stack’ (per una finestra basata dinamicamente sul 
contenuto di sp). Questo può tirarci fuori dalle situazioni più 
complicate. Naturalmente quando MS scrive il contenuto di 
una di queste finestre nel file-registrazione, include anche il 
suo nome. 

MS ci permette di cambiare il contenuto di una locazione di 
memoria o di un registro semplicemente selezionandoli col 
mouse. A seguito della selezione, appare un requester nel quale 
possiamo scrivere il nuovo valore. Possiamo inoltre cambiare 
un’istruzione direttamente in memoria, inserendola in formato 
assembly. Se abbiamo una finestra sulla memoria possiamo 
scegliere fra la visualizzazione in formato dati e in formato co¬ 
dice. Nell'ultimo caso possiamo alterare un’istruzione selezio¬ 
nandola con il mouse. 

Le prossime due caratteristiche sono presenti solo nella versio¬ 
ne più recente (e non ancora pubblicata) di MetaScope. L’auto¬ 
re mi ha assicurato che l’update dovrebbe essere disponibile 
per il tempo in cui leggerete questo articolo. 

MS può salvare una configurazione fatta di: breakpoint perma¬ 
nenti. locazioni delle finestre, dimensioni, espressioni usate per 
calcolare indirizzi base e status (congelati o meno). In questo 
modo possiamo preparare la nostra sessione di debugging co¬ 
me più ci piace e poi salvarla, per non doverla reimpostare tut¬ 
ta la prossima volta che iniziamo una nuova sessione. 

Continua a pagina 66 
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Estendiamo l’uso dei nostri comandi 


Wildcard in offerta speciale 


di Dan Schein 

Tutti noi abbiamo dei comandi che ci piacerebbe usare con più 
argomenti o con le -wildcard. Un esempio è il programma MO¬ 
RE di Carolyn Scheppner. fornito con la versione 1.2 e 1.3 del 
disco Workbench. 

Questo programma è un lettore di testo di alta qualità che pre¬ 
senta caratteristiche di funzionamento avanzate, come lo scrol- 
ling bidirezionale del testo, la ricerca bidirezionale di stringhe 
nel testo e (nella nuova versione dell' 1.3) la possibilità di mo¬ 
dificare il file che si sta leggendo. Più di una volta avrei voluto 
digitare: 

MORE pìppo.bar pippo.c 

ma solo il primo file verrebbe visualizzato da MORE. Il secon¬ 
do argomento rimarrebbe semplicemente ignorato. 

Qualche tempo fa, mi sono detto che ci deve essere un modo 
semplice (e facile) per fare sì che programmi come questo ac¬ 
cettino più di un argomento alla volta. Così, dopo un po' di 
pensamenti, un po' di hacking e qualche cheeseburger sono ar¬ 
rivato a questa soluzione. 

Ho chiamato questo programma EXT. in quanto può essere 
usato come EXTension (estensione) di praticamente qualsiasi 
altro programma. 

Il principio che anima EXT è abbastanza semplice e si capisce 
meglio se prima si dà un'occhiata alla sua sintassi d'uso: 

EXT [-e] COMMAND (filenamel,...,filenameN).ext 

EXT [-e] COMMAND filename.(ext1extN) 

COMMAND - comando che deve essere eseguito 
filename - nome del file SENZA estensione 
ext - estensione del file 
-e - solo eco, non eseguire 

Vediamo adesso alcuni esempi: 

1 EXT MORE dfO:msdos/read(me.fnf,.me) 


2 EXT MORE sre :c/Pnews-(e,m) .c 

3 EXT ADDBUFFERS DF(0,1): 200 

Nell’esempio numero 1, EXT viene usato per estendere la 
stringa 'MOREdfO:msdos/read' con le stringhe racchiuse al¬ 
l'interno della parentesi rotonda, una alla volta, naturalmente. 
Questo esempio sarebbe uguale a: 

MORE df0:msdos/readme.fnf 

MORE df0rmsdos/read.me 

Nel secondo esempio, EXT viene usato per estendere la parte 
centrale di una stringa, anziché la parte iniziale o finale. Que¬ 
sto significa che corrisponde ai comandi: 

MORE sre :c/Pnews-e.c 
MORE sre :c/Pnews-m.c 

Il terzo esempio mostra la capacità di EXT di passare più di un 
argomento a un comando. II numero di argomenti che potete 
utilizzare è limitato unicamente dalla lunghezza della linea di 
comando del DOS (DOS_COMMAND_LINE). Per definizio¬ 
ne questa stringa è lunga 255 caratteri. Il terzo esempio equiva¬ 
le ai seguenti comandi: 

ADDBUFFERS DFO: 200 

ADDBUFFERS DF1: 200 

Il numero di argomenti che EXT può gestire è limitato solo 
dalla lunghezza della linea di comando del sistema. EXT può 
gestire fino a 254 caratteri su Amiga. L’unica reale limitazione 
di EXT è che non dovrebbe essere usato con comandi o pro¬ 
grammi che necessitano di interagire con l’utente tramite il 
CLI dal quale sono stati lanciati. 

Se, per esempio, digitiamo: 

EXT diskeopy dfO: to df(l,2): 


un 


b 


























---[ u|n 

il programma Diskcopy parte immediatamente, senza aspettare 
che l’utente prema il tasto RETURN come normalmente ri¬ 
chiesto. Questo è causato dal fatto che il programma che viene 
esteso non possiede un canale stdin. In questo caso, Diskcopy 
si limita a procedere, ma altri programmi potrebbero compor¬ 
tarsi in maniera differente. Basta tenere a mente che questa li¬ 
mitazione è la stessa di cui soffre il comando RUN fornito 
dalla Commodore. Se, quindi, un programma o un comando 
non può essere lanciato con RUN, allora non può essere lancia¬ 
to neanche con EXT. 

numero - ED) 

/*************************************************** 

(C) Copyright 1989 by Sneakers Computing 

2455 McKinley Ave. 

West Lawn, PA 19609 

(215) 678-8984 

Il codice sorgente di EXT 

UUCP: sneakers@heimat 

Il programma è stato scritto in modo da poter essere portato fa¬ 
cilmente su molti sistemi operativi diversi (vengono in mente 
MS-DOS e UNIX). Ho messo tutte le cose che potrebbero ri¬ 
chiedere cambiamenti in una semplice istruzione define all’ini¬ 
zio del listato. 

All Rights Reserved 

Questo sorgente e il risultante eseguibile possono 
essere usati (e modificati) per qualsiasi scopo, a 
patto che (#1) non siano venduti e (#2) non siano 
inseriti o usati in un prodotto commerciale. Per 

Le uniche altre due parti che potrebbero dover essere cambiate 
o rimosse sono le linee che precedono e che seguono la nota di 
copyright (nella routine print usage). Queste due linee cam¬ 
biano il colore del cursore e potrebbero avere effetti indeside¬ 
rati su sistemi diversi da Amiga. 

ulteriori informazioni contattate l'indirizzo 

sopracitato. 

Nome programma: EXT.c 

Scopo: Questo programma offre un'estensione per 

EXT è stato scritto e compilato con il Lattice C V5.0. Usando 
la sintassi contenuta nei commenti di intestazione, EXT può 
essere compilato in modo da diventare pure e da poter quindi 
essere reso residente con il comando resident fornito con il 
Workbench V1.3. 

altri programmi e comandi per mezzo di 
un metodo di sostituzione di stringhe. 

Versione: Versione 1.00 

Creata: 01/29/1989 

Il codice sorgente è riccamente commentato in modo che il 
programmatore C principiante o esperto possa capire la teoria e 
il funzionamento di EXT. EXT costituisce anche un buon 
esempio dell’uso dei puntatori C e dei benefici che essi posso¬ 
no apportare a programmi scritti come si deve. 

Programmatore: Dan "Sneakers" Schein 

OS: AmigaDOS VI.3 

Compilatore: Lattice V5.0 

Vorrei ringraziare Carolyn Scheppner per avere scritto MORE, 
per avere sopportato le mie stupide domande quando imparavo 
il C e anche per avere ricontrollato questo articolo e il codice 
sorgente di EXT. 1 suoi commenti sono stati (come sempre) 
portatori di riflessione e di grande aiuto. 

Comandi comp. : Le -tr -L ext 

Nota: Il flag M -tr" farà si che venga fatto il link 
con "cres.o", rendendo EXT "pure" in modo che 
possa essere usato come comando residente. 

Copyright 

*★************************************************★/ 

E adesso, per i malintenzionati, le note di copyright. Il codice 
sorgente di EXT e il risultante eseguibile possono essere usati 
(e modificati) come desiderate, a patto che non vengano ven¬ 
duti e che non siano inclusi o utilizzati in alcun prodotto com¬ 
merciale. 

♦include <stdio.h> 

♦include <stdlib.h> 

♦include <string.h> 

♦include <ctype.h> 

Il sorgente di EXT e il suo eseguibile possono essere riversati 
su BBS e su servizi commerciali e possono essere distribuiti 
anche su dischi PD/ Shareware. 

/* 

* DOS_COMMAND LINE è il numero massimo di 

* caratteri che il sistema operativo accetta 

* in una linea di comando. 

Questo è tutto! Se non avete un compilatore C o non volete di¬ 
gitare il codice sorgente, l’eseguibile e il sorgente stesso sono a 
vostra disposizione per potere essere scaricati dalla BERKS 
AMIGA BBS (USA: 215/678-7691 a 1200/2400 baud). (sono 
anche disponibili sul dischetto di Transactor relativo a questo 

★ 

* L'idea che sta dietro questo programma è di 

* renderlo il più facilmente portabile 

* possibile. Solo i seguenti "ifdef" 

* dovrebbero eventualmente essere modificati 

1 1 30 | 
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* per portare il codice su MS-DOS o UNIX! 

k 

*/ 

#define AMIGADOS 


argv++; 
argc—; 

} 

/* 

* Costruisci una stringa con gli argomenti 

* della linea di comando 


#ifdef AMIGADOS 
#define LEN 3 

Idefine DOS_COMMAND_LINE 255 
#endif 

/* 

* Queste definizioni rendono semplicemente 

* il codice più leggibile 

* 

*/ 

tdefine LPAREN ' (' 

#define RPAREN ')' 

#define SPACE ' ' 

#ifndef FALSE 
#define FALSE 0 
#endif 

#ìfndef TRUE 
#define TRUE ! FALSE 
#endif 

void main(); 

void print_usage(); 

void main (argc, argv) 
int argc; 
char **argv; 

{ 

int i, echo_only=FALSE; 

char *lparen, *rparen, *first_arg, *last_arg; 
char *nextdelim; 

char oldcmdline[DOS_COMMAND_LINE]; 
char newcmdline[DOS_COMMAND_LINE]; 

/* 

* Controlla se l'utente vuole aiuto. 

* 

*/ 

if ((argc < 2) || (argv[l][0] == '?')) 

print_usage ( ) ; 

/* 

* Guarda se l'utente vuole solo l'eco. Se sì, 

* setta l'apposito flag e incrementa argv in 

* modo da saltare "-e", poi diminuisci argc di 

* uno così corrisponde al restante numero di 

* argomenti argv. 

k 

*/ 

if <(argv[l][0] == '-') SS 

toupper(argv[l][1]) == 'È) { 

echo_only=TRUE; 


for (i=0, oldcmdline [0] =NULL; i<argc; i++) 

{ 

strcat(oldcmdline, argv[i]); 
strcat(oldcmdline, " "); 

} 

/* 

* Crea un puntatore alla parentesi tonda 

k 

* NULL se non esiste 

k 

*/ 

lparen = strchr(oldcmdline, LPAREN); 
rparen = strchr(oldcmdline, RPAREN); 

/* 

* Controlla che la sintassi sia valida. 

* In caso negativo, mostra l'help 

* 

* Gli errori di sintassi sono... 

k 

* Parentesi chiusa prima di parentesi aperta, o 

* non esiste parentesi aperta, o 

* non esiste parentesi chiusa 

* 

*/ 

if ((rparen<lparen) || !lparen J | !rparen) 

print_usage(); 

/* 

* Crea un puntatore all'estensione (se esiste) 

k 

*/ 

last_arg = (rparen+1); 

/* 

* Copia la linea di comando fino (ma non 
inclusa) 

* alla parentesi aperta in una nuova stringa. 

k 

* Metti un NULL in fondo alla nuova stringa. 

* 

* Crea un puntatore al primo argomento dopo la 

* parentesi aperta. 

* Incrementa il puntatore alla parentesi aperta. 

k 

*/ 
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strncpy(newcmdline,oldcmdline,lparen-oldcmdline); 
newcmdline[lparen-oldcmdline]=NULL; 
first_arg=&newcmdline[strlen(newcmdline)]; 
lparen++; 

/* 

* Entra in un ciclo (loop), trovando la prossima 

* stringa di sostituzione e quindi aggiungendola 

* alla nuova linea di comando e facendola 

* seguire dall'eventuale testo di estensione. 

■k 

* Naturalmente tutto questo è fatto per mezzo 

* puntatori, anziché di stringhe vere e proprie. 

* 

* Continua a rimanere nel loop fino a quando 


* esauriamo le stringhe di sostituzione, 
uscendo 

* poi con il comando BREAK. 

*/ 

for(; ;) { 

* fir st_arg=NULL; 

nextdelim=strpbrk(lparen, ",)"); 

* nextde1im=NULL; 

strcat(first_arg, lparen); 
strcat(first_arg, last_arg); 

if (echo_only) 

printf("ext: %s\n", newcmdline+LEN); 
else if (System (newcmdline+LEN)) 

printf("ext: ERROR EXECUTING \"%s\"\n", 

newcmdline+LEN), 

lparen=nextdelim+l; 
while (‘lparen == SPACE) 
lparen++; 

if (lparen >rparen) 
break; 

} 

exit (0) ; 


void print_usage() 

{ 

char esc = '\33'; 

/* 

* Le sequenze di escape utilizzate qui sotto 

* potrebbero causare dei problemi su sistemi 

* operativi diversi da Amiga. Nel caso, 

* rimuovetele. 

*/ 

printf ("%c [0; 1; 33; 40m", esc) ; 
printf("EXT VI.0 (C) 1989 by Sneakers 
Computing\n\n”); 

printf("%c[0;31;40m",esc); 
printf("Uso: ext [-e] COMMAND 

(filenamel , , filenameN).ext\n"); 


printf(" ext [-e) COMMAND 

filename.(extl,...,extN)\n\n"); 

printf("Dove COMMAND = comando da eseguireXn") 
printf(" filename = nome del file SENZA 

estensione\n"); 

printf(" ext = estensioneVn"); 

printf(" -e = solo eco, non 

eseguire\n\n"); 

printf("Esempi : ext TYPE (Mail,News).c\n"); 

printf(" ext LIST 

df0 : sre/day.(c,bak)\n"); 

printf(" ext ADDBUFFERS ff(s,sl,s2): 

200\n"); 

exit (1); 


Sul prossimo numero: 

• Programmare in ARexx 

• L’arte della programmazione in 
linguaggio Assembly 

• I dischi di Fred Fish 

• Algoritmo veloce di riempimento 
aree 

• L’uso dei gedget multipli 

• Lo standard IFF 

• Il linguaggio Assembly su Amiga, 
seconda parte 

• Come disegnare usando la libreria 
grafica da C e da Basic 

. Il MIDI 

• Notizie dal mondo Amiga 

• ViewPort 
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I Servizi 

di 



Amiga Transactor offre una serie di servizi per agevolare i propri lettori nel reperimento di software e materiale utile alla 
programmazione. 

È disponibile l'intera libreria di dischetti di pubblico dominio curata da Fred Fish. Ogni dischetto contiene numerosi 
programmi e utility, spesso corredati da listati sorgenti e commenti degli autori. 

Per districarsi fra le centinaia di programmi disponibili nei dischi di Fred Fish, è stato creato un apposito catalogo di 20 
pagine. Tale elenco riporta, divisi per categoria e in ordine alfabetico, tutti i programmi presenti, completandoli con 
informazioni quali la descrizione della funzione, l’autore, il numero di versione, la disponibilità del sorgente e il disco nel 
quale sono contenuti. I dischetti possono essere ordinati contrassegnando i numeri desiderati, purché la quantità sia un 
multiplo di cinque. Per ordini amministrativi saremo costretti a non accettare ordini che non soddisfino questa regola. Tutto 
il materiale, a esclusione dei listati pubblicati sulla rivista, viene fornito nella versione originale americana, senza 
traduzione o modifiche. 

A ogni numero della rivista corrisponde un disco chiamato “AmiTrans Disk” che contiene tutti i listati pubblicati su quel 
numero, nonché i corrispondenti eseguibili e tutti gli altri programmi di pubblico dominio menzionati negli articoli. 


BUONO D’ORDINE 

Completa il buono d’ordine (o una sua fotocopia) e spedire in busta chiusa a: I servizi di Transactor per Amiga - Via Rosellini, 12 - 20124 Milano 

Si può allegare: assegno, contanti o fotocopia della ricevuta di versamento c/c n. 11666203 intestato a Gruppo Editoriale Jackson. 

Non si effettuano spedizioni contrassegno 

Desidero ricevere i seguenti articoli; contrassegnare con una X i numeri di Fish disk desiderati (a gruppi di 5) 



Nota: Il disco 164 non è disponibile 
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DESCRIZIONE 

□ Fish Disk 

□ Catalogo 

□ AmiTrans Disk #1 

□ #2 #3 #4 


Lit. 35.000 per gruppo di cinque 

Lit. 15.000 aggiornato fino al Fish 138 

Cognome .... 

Nome. 

Via . 

Cap. 

... Città. 

Lit 15.000 

Lit 15.000 

Prov. 

Firma. 

... Tel. 


(se minorenne quella di un genitore) 

Tutti i prezzi sono da intendersi IVA inclusa e spese di spedizione comprese. Gli ordini non firmati non verranno evasi. 
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Obbedire alle regole! 


La coerenza è la base dell interfaccia utente 


di Andy Dawson 

Andy Dowson è un importante dirigente nel campo dei mass¬ 
media che ha lavorato con l'Amiga fin dalla stia nascita. E 
laureato con lode in psicologia e si è specializzato in psicolo¬ 
gia dell' interfaccia utente. Andy ha lavorato come consulente 
in varie organizzazioni di grandi dimensioni, dando consigli 
sui vari aspetti della presentazione dei computer e dell’intera¬ 
zione con l'utente. 

All’inizio la Commodore stabilì alcune regole fondamentali 
per gli sviluppatori. 

Dissero innanzitutto che vi era un solo indirizzo assoluto in tut¬ 
ta la macchina e che si trovava a $4; a qualsiasi cosa si dovesse 
accedere, bisognava farlo attraverso tale indirizzo, sia che si 
trattasse di una routine del Kernel situata in ROM, sia di un'a¬ 
rea dati di sistema o di una parte deU’hardware. Coloro che os¬ 
servarono questa regola notarono che il loro software si 
adattava a diversi modelli e varianti del sistema operativo sen¬ 
za difficoltà. Chi invece ignorò questa norma scoprì che il suo 
software si disgregava non appena veniva fornita una nuova 
versione del sistema operativo o veniva introdotta una nuova 
macchina. 

Con Intuition la Commodore creò anche un ambiente base per 
finestre, icone, mouse e puntatori (sappiamo tutti che si tratta 
dell’ambiente WIMP). Questa è la base del Workbench, e la 
maggior parte delle case produttrici di software ha accettato 
questa regola come un modo gradevole di affrontare i pro¬ 
grammi. Ma Intuition non era solo una caratteristica del Wor¬ 
kbench, si trattava piuttosto di una completa filosofia Amiga 
mirata ad enfatizzare e migliorare il concetto di software inte¬ 
grato. Intuition venne progettato per rendere la vita più facile e 
semplice all’utente finale, e per fare in modo che il sistema 
Amiga, che include la gamma del software commerciale, fosse 
un sistema veramente coerente. 

I concetti base di Intuition sono le finestre, le icone ed i menu. 
Si basava sull’idea che l’utente finale non avrebbe dovuto aver 
bisogno di imparare complesse combinazioni di tasti per avvia¬ 
re le sue applicazioni; così si scelse il sistema "point-and-sho- 
ot", ovvero "punta e spara", prima usato dalla Xerox e poi reso 
popolare dall’Apple Macintosh. L’Amiga Commodore adottò 
ed estese questo sistema per andare incontro alle necessità di 


un sistema multi-tasking. La loro intenzione era quella di forni¬ 
re un metodo intuitivo per tutto il software Amiga, rendendo 
così il primo stadio della curva di apprendimento meno trau¬ 
matico di quanto avrebbe potuto essere. 

Per l’utente novello tale metodo intuitivo è di immenso valore, 
e in questo modo molte persone "anti computer" sono state 
convinte molto velocemente dalla facilità con la quale, per 
esempio, riuscivano a disegnare con DeluxPaint o a creare 
semplici documenti con TextCraft. Anche l’utente occasionale 
di software ne può beneficiare, non ha più bisogno di studiarsi 
il software sui manuali mentre può creare, basandosi sul l'espe¬ 
rienza passata e guidato dall’interfaccia intuitiva. 

Tuttavia, se l’utente si limita a un solo programma applicativo 
o se si tratta di un utente molto regolare, il meccanismo del 
metodo intuitivo può diventare noioso. Subito si appresterà a 
costruire una mappa cognitiva della struttura del programma. 
Automaticamente vengono apprese tutte le vie seguite dal pro¬ 
gramma (presumendo che sia scritto bene e che sia coerente!) e 
il mouse potrebbe diventare un ostacolo. 

Quasi tutti gli utenti utilizzeranno regolarmente uno o due pro¬ 
grammi software, e questi faranno parte di quel pacchetto che è 
andato oltre lo stadio dell’interfaccia intuitiva. I tasti funzione, 
le combinazioni con il tasto Amiga e le "Meta-key" diverranno 
la norma. A dire il vero le caratteristiche più estese verranno 
ancora richiamate usando i menu o le icone, ma per la maggior 
parte delle operazioni si potrebbe non utilizzare il mouse e 
buttarlo dalla finestra. 

Ogni tanto tutti questi utenti spazieranno brevemente verso al¬ 
tri programmi, perché per esempio vogliono pasticciare con un 
database, o perché improvvisamente scoprono che hanno biso¬ 
gno di fare un disegno per illustrare il loro testo, o magari han¬ 
no bisogno di lavorare con il foglio elettronico che avevano 
messo da parte sin da quando lo hanno comperato. In questo 
caso il metodo intuitivo non è secondo a nessuno e, con un’in¬ 
terfaccia utente coerente e costante. l’Amiga e il suo software 
diventano un pacchetto d’eccezione, inspirando molta fiducia 
da parte dell’utente. 

Questa è la filosofia Amiga. 
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I Menu di Intuition 

Con Intuition si creò una grande quantità di menu e per assicu¬ 
rare la coerenza in tutta la gamma del software Amiga la Com¬ 
modore stabilì inizialmente alcune regole fondamentali per i 
due menu che venivano usati più frequentemente. Crearono un 
menu standard project ed un menu standard edit. 

II menu project era costituito da: 

NEW - il quale crea semplicemente un nuovo progetto 
OPEN - il quale riporta al progetto precedentemente salvato 
SAVE - salva il progetto attuale sul disco 
SAVE AS - salva il progetto attuale con un nuovo nome 
PRINT - stampa l'intero progetto 

PRINT AS - stampa il progetto ma permette all’utente di alte¬ 
rare i default 

QUIT - esce dal programma ma avvisa l’utente se il progetto è 
stato modificato ma non salvato. 

Molte software house hanno accettato questa convenzione, 
sebbene sembri che alcuni dei pacchetti più grossi l’abbiano 
ignorata. Per esempio, WordPerfect usa un'insensata ed inutile 
collezione di sotto menu retrieve e save, mentre SuperBase ha 
modificato il menu standard project per fare fronte alla natura 
specialistica del sistema del database. 

Altri pacchetti tendono a conformarsi, sebbene gli utenti alle 
prime armi si confondano spesso quando si trovano di fronte a 
OPEN di certi pacchetti e LOAD di altri. Una differenza nei 
nomi implica una differenza nelle operazioni, ed ecco che si 
distrugge immediatamente il fondamento base del metodo in¬ 
tuitivo. 

Il menu edit è molto più appropriato per un word processor o 
per un programma di disegno, sebbene anche i fogli elettronici, 
i database, i pacchetti di grafica e musica sarebbero in grado di 
usarlo. 

Lo standard Commodore era: 

UNDO - cancella l’operazione precedente (se non è possibile, 
tale opzione andrebbe disabilitata!) 

CUT - rimuove la porzione selezionata e la registra nella Clip- 
Board 

COPY - copia la porzione selezionata nella ClipBoard 

PASTE - inserisce nel progetto la copia che si trova nella Clip- 
Board 

ERASE - rimuove la porzione selezionata senza registrarla 
nella ClipBoard 


Ogni progetto che dichiara di essere in grado di lavorare in 
multi-tasking deve dare un completo supporto alla ClipBoard. 
Sfortunatamente non sempre è così e quindi i prodotti di molte 
software house non diventano parte di un sistema integrato 
semplicemente perché ignorano il concetto di ClipBoard. 

La Commodore-Amiga ha chiaramente interpretato la curva di 
apprendimento intuitivo, e ha anche capito che, con un po’ di 
esperienza, molti utenti sarebbero rimasti attaccati alla tastiera 
per la maggior parte del tempo. Hanno quindi dato a Intuition 
la capacità di richiamare le funzioni dei menu utilizzando delle 
abbreviazioni sulla tastiera. La Commodore non ha così solo 
stabilito alcune regole base per i menu, ma ha anche dato degli 
standard per le abbreviazioni su tastiera. Sotto molti aspetti è 
ancora più importante che si adotti questo standard, poiché le 
opzioni dei menu, nella maggior parte dei casi, si spiegano da 
sole e l’utente non ha bisogno di memorizzarle. Tuttavia la co¬ 
sa principale, per quanto riguarda le abbreviazioni da tastiera, è 
che queste devono essere memorizzate, quindi la coerenza nei 
diversi pacchetti è di immensa importanza. 

La Commodore ha dato due raccomandazioni per le abbrevia¬ 
zioni da tastiera. La prima riguardava le opzioni dei menu, da 
usare con il tasto Amiga destro, e questo in effetti era una so¬ 
stituzione per le funzioni alle quali si accedeva con il tasto de¬ 
stro del mouse. La seconda riguardava una selezione più 
generale all’interno di un progetto (che normalmente corri¬ 
sponde alle funzioni del tasto sinistro del mouse) da usare con 
il tasto Amiga sinistro. Il fatto che gli utenti sarebbero stati in 
grado di tenere premuto il tasto Amiga con il mignolo di una 
mano, e premere uno dei tasti normali che di solito premevano 
con l’altra, faceva parte delle direttive Amiga. In questo modo 
i dattilografi esperti avrebbero potuto usare le abbreviazioni 
senza sentirsi impacciati o goffi. 

Per quanto riguarda le abbreviazioni dei menu la Commodore 
raccomanda di utilizzare le seguenti (sebbene vi sia un conflit¬ 
to con l’abbreviazione costituita dalla combinazione del tasto 
Amiga sinistro con P, che sembra avere due funzioni - sembra 
che nessuno sia riuscito a risolvere questo dilemma, mentre la 
Commodore nel programma NotePad usa la combinazione del 
tasto Amiga sinistro e & per il paste!): 


Amiga 

sinistro 

X 

- taglia (cut) 



Amiga 

sinistro 

c 

- copia (copy) 



Amiga 

sinistro 

p 

- incolla (paste) 


Amiga 

sinistro 

I 

- seleziona il 

corsivo 

Amiga 

sinistro 

B 

- seleziona il 

neretto 

Amiga 

sinistro 

U 

- seleziona il 

sottolineato 

Amiga 

sinistro 

P 

- rimette lo stile 

normale 

Amiga 

sinistro 

Q 

- esegue un undo o 

cancella 

Amiga 

sinistro 

S 

- salva 




Come per le abbreviazioni, la Commodore ha specificato alcu¬ 
ni tasti generali da utilizzare per selezionare delle porzioni che 
si trovano a destra o a sinistra del cursore, a seconda del pro¬ 
getto, soprattutto in un word processor: 

Amiga destro I - seleziona piccole parti alla 
destra del cursore (parole) 
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Amiga destro 0 - seleziona parti più grandi a 
destra del cursore (frasi) 

Amiga destro P - seleziona parti ancora più grandi 
a destra del cursore (paragrafi) 

Amiga destro J - seleziona piccole parti a 
sinistra del cursore (parole) 

Amiga destro K - seleziona parti più grandi a 
sinistra del cursore (frasi) 

Amiga destro L - seleziona parti ancora più grandi 
a sinistra del cursore (paragrafi) 

La Commodore ha anche stabilito che le combinazioni tasto 
Amiga destro N e tasto Amiga destro M servivano a portare lo 
schermo Workbench dietro o davanti, e che lo stesso Intuition 
si sarebbe occupato di questo, per cui il software non deve usa¬ 
re queste combinazioni per altri scopi. 

Alcune software house hanno accettato queste convenzioni . 
Per esempio WordPerfect usa l'abbreviazione Amiga destro I 
per selezionare il resto della parola che si trova a destra del 
cursore. Sebbene in alcune parti faccia a modo suo, si confor¬ 
ma alle regole generali di Intuition raccomandate dalla Com¬ 
modore. 

La domanda inevitabile che sorge da tutto questo è: perché è 
necessario adottare questi standard? 

L’unica risposta a questo è che serve a rendere la vita più facile 
all’utente finale. Pensate a un utente finale che usa diversi pac¬ 
chetti suU’amiga. Usando per esempio un word processor per 
la maggior parte del tempo si abituerà alle convenzioni di ta¬ 
stiera di quel pacchetto, ma forse gli capiterà anche di dover 
usare di tanto in tanto un database o un foglio elettronico. Im¬ 
maginate la sua confusione se scopre che le combinazioni sulla 
tastiera hanno funzioni diverse dalla norma, magari così diver¬ 
se che vi è persino il rischio di rovinare l’intero lavoro. 

Una ragione per la quale alcune software house modificano gli 
standard è che il loro software è stato scritto per lavorare su di 
una gamma di computer i cui standard sono forse leggermente 
diversi (sempre che posseggano degli standard). La ragione a 
sostegno di questo è che l’utente che usa uno stesso program¬ 
ma su di una macchina qualsiasi vuole trovare lo stesso am¬ 
biente sull’Amiga. Considerando che la percentuale di tali 
utenti probabilmente corrisponde a meno di una frazione del¬ 
l’uno per cento, ma che quasi il cento per cento degli utenti di 
quel programma useranno anche altri programmi sull’Amiga, 
la questione non è neanche da discutere. È molto più probabile 
che la politica interna della società abbia stabilito che è più fa¬ 
cile produrre un solo manuale per tutte le macchine, e che per¬ 
sonalizzare il nucleo del software di ogni computer è una 
perdita di tempo e denaro. Queste tesi ignorano completamente 
le realtà della vita, ignorano totalmente l’utente finale e, so¬ 
prattutto, implicano che lo stesso software non è di alcuna utili¬ 
tà se non viene usato nel suo ambiente specifico. 

Vi è anche un pacchetto che, persino nelle varie sezioni dello 
stesso programma, possiede diverse convenzioni mescolate tra 
loro! In alcuni casi, la combinazione Amiga sinistro X esegue 
il CUT (come avviene in un requester del testo fornito da Intui- 


tion) ma in altri casi la stessa combinazione non esegue il CUT 
del testo, tuttavia permette all’utente di cambiare le directory 
nelle quali sta lavorando; a questo punto per cancellare il testo 
bisogna usare CTRL-X! Questo è solo uno degli esempi, co¬ 
munque non fa nulla per dare all’utente un po’ di confidenza. 
Molti utenti finali probabilmente non noteranno mai le frustra¬ 
zioni prodotte da tali incoerenze, ma le loro prestazioni e l’opi¬ 
nione che avranno del prodotto inconsciamente verranno 
intaccate. 

Lo stesso problema succede anche con l’Amiga, poiché usando 
il CLI, CTRL-X ha la funzione del CUT, mentre usando uno 
"string gadget" viene utilizzata la combinazione L-Amiga X. 

La coerenza ed il multi-tasking 

In Amiga, come in tutti gli ambienti in multi-tasking, la coe¬ 
renza è di vitale importanza. A livello software è NECESSA¬ 
RIO obbedire alle regole altrimenti i programmi in 
competizione per le risorse del sistema si scontreranno ed infi¬ 
ne si bloccheranno sotto i nostri occhi. In sistemi più semplici 
tale coerenza non sempre è necessaria. 

Anche a livello di interfaccia utente la coerenza è estremamen¬ 
te importante. In un sistema semplice a singolo programma, 
l’incoerenza non ha molta importanza poiché il passaggio da 
un programma all’altro richiede del tempo e l’utente apprende¬ 
rà presto gli indizi relativi ad esso che lo aiuteranno ad orien¬ 
tarsi nell’ambiente di quel programma proprio come un 
guidatore di una macchina con guida a destra si può di solito 
abituare velocemente alla guida a sinistra, perché si trova in un 
ambiente diverso per un ragionevole periodo di tempo. Tutta¬ 
via. in un sistema multi-tasking, ove è possibile che un databa¬ 
se ed un word processor lavorino allo stesso tempo, il 
commutare dall’uno all’altro non dà molti indizi riguardo al 
programma e l'utente è quasi costretto a trasferire la memoria 
delle combinazioni basilari oltre i confini del programma. Se 
tali combinazioni non sono coerenti sorgono dei problemi, co¬ 
me sorgerebbero per un guidatore di un'automobile con guida 
a destra al quale si trasferisse la guida a sinistra e viceversa ad 
ogni cambio di marcia! 

Forse quello che voglio dire in questo articolo è che le software 
house dovrebbero guardare oltre i loro prodotti, verso il siste¬ 
ma Amiga nel suo insieme. Per favore, dimenticatevi della 
coerenza all’interno della vostra produzione (a meno che possa 
essere adattata senza interferire con le regole base dell’Amiga) 
e lavorate per un ambiente Amiga coerente. Sfortunatamente 
credo che, in alcuni pacchetti Amiga, l’arroganza e un certo 
grado di disprezzo per l’utente finale siano già emersi, così da 
rovinarli. 

Questo articolo dà per scontata l’intera psicologia dell’interfac¬ 
cia utente. E un argomento complesso e viene raramente capito 
persino dai migliori autori di software. 


Continua a pagina 82 
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Programmare in ARexx 


Parte 1 - sintassi, simboli, operatori e opzione trace 


di John Carpenter 

ARexx è un linguaggio di programmazione di sistema che. a 
parte le normali caratteristiche di un linguaggio, permette ai 
task di Amiga di comunicare direttamente fra di loro. Si posso¬ 
no costruire complesse sequenze di comando simili a quelle 
del CLI e un programma ARexx, o un programma applicativo 
che sia provvisto di interfaccia ARexx, può pilotare program¬ 
mi esterni (incluso del software applicativo come, per esempio, 
SuperBase). Molti programmi commerciali sono ormai forniti 
di una interfaccia ARexx e il futuro sembra molto promettente. 

E stato con grande eccitazione che ho letto, alcuni mesi fa, un 
articolo che annunciava che William Hawes aveva implemen¬ 
tato il linguaggio Rexx su Amiga chiamandolo ARexx. 

Rexx è un’abbreviazione per Restructured Extended Execu- 
tor, un linguaggio sviluppato da Mike Cowlishaw dei laborato¬ 
ri IBM inglesi. In origine fu pubblicato (almeno così credo) 
come sostitutivo del linguaggio EXEC che girava su CMS, fa¬ 
cente parte del sistema operativo VM delEIBM. 

L'implementazione Amiga segue fedelmente la definizione del 
linguaggio come descritta nel libro "The Rexx Language: A 
Practical Approach in Programming" di M. F. Cowlishaw, 
pubblicato da Prentice Hall. 

Rexx, come il BASIC, è un interprete, e questo, fatta eccezione 
per alcune parole chiave in comune, mette fine alle similarità 
fra i due linguaggi. Possiede una sofisticata interfaccia per le 
istruzioni che gli permette di lanciare programmi esterni e di 
comunicare con essi, rendendo possibile al programmatore lo 
sviluppo di pacchetti software completamente integrati. 

Rexx è molto facile da usare anche per un principiante. La sin¬ 
tassi del linguaggio è uniforme e non soffre delle specializza¬ 
zioni di cui soffrono alcuni dialetti del BASIC. Una delle 
caratteristiche migliori per il principiante (e per il programma¬ 
tore esperto) consiste nella superba possibilità offerta dal modo 
trace per il debugging a livello di codice sorgente. 

Un programma Rexx 

Un programma Rexx consiste in un testo ASCII (che può esse¬ 
re creato usando qualsiasi editor che produca un file ASCII co¬ 


me output) contenente una serie di frasi. Una frase consiste in 
spazi bianchi (che vengono ignorati, a meno che non fungano 
da delimitatori o facciano parte di una stringa), parole chiave 
Rexx, simboli e caratteri speciali. Le parole chiave Rexx sono 
nomi riservati per le istruzioni Rexx. 

I simboli si dividono in commenti, stringhe, simboli speciali, 
numeri e operatori. I caratteri speciali sono ( ) , ; : e hanno un 
significato particolare quando sono al di fuori di una stringa. 

Una frase è delimitata da un carattere di new-line, eccetto 
quando l'ultimo carattere nella linea è una virgola (fatta ecce¬ 
zione per i commenti), o quando la linea termina nel bel mezzo 
di una stringa o di un commento. La frase, che d’ora in poi 
chiameremo linea di istruzione, può essere esplicitamente ter¬ 
minata utilizzando il punto e virgola (;). 

Gli spazi bianchi, a eccezione di quelli contenuti nelle strin¬ 
ghe, sono sempre ridotti a un singolo carattere di spaziatura, 
mentre le linee vuote vengono ignorate. Dopo questa compres¬ 
sione, la linea di istruzione viene letta da sinistra a destra dal¬ 
l’interprete. 

I commenti consistono in una qualsiasi sequenza di caratteri 
delimitata da /* e da */ e possono riempire più di una linea. 
Possono anche essere inseriti in mezzo ad altri simboli. I com¬ 
menti vengono ignorati dall’interprete che li tratta come sepa¬ 
ratori e li converte quindi in un singolo spazio. 

I programmi Rexx devono iniziare con un commento. Questo è 
stato fatto per mantenere la compatibilità fra i programmi Rexx 
e i programmi EXEC deH'ambiente CMS. 

Le stringhe 

Una stringa è una sequenza di caratteri da usare così come so¬ 
no. Viene delimitata dall’apice (’) o dai doppi apici ("). Posso¬ 
no essere usate anche stringhe in binario o in esadecimale. 


"abc" 
' abc' 


/* stringa nulla o vuota */ 
/* stringa contenente abc */ 
/* stessa stringa delimitata 
diversamente */ 
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'John''s book' /* John's book. I due apici 

Se la seguente parte di programma Rexx fosse eseguita: 


indicano un apice singolo */ 

"John's book" /* equivalente al precedente */ a=3 /* assegna 3 alla variabile A */ 

"lui disse, ""aiuto""" /* diventa: lui b=l /* assegna 1 alla variabile B (notare 

disse, "aiuto" */ che gli spazi vengono eliminati prima 

'12AB'x /* stringa esadecimale */ dell'esecuzione) */ 

”12 ab"x /* equivalente al precedente */ c.a.b = 'Amiga' /* assegna "Amiga" 


'00000001'b /* stringa binaria */ 

all'elemento C.3.1 */ 

d='John' 

I simboli 

e.john = 'Fred' /* assegna "Fred" a E.JOHN */ 
Say c.3.1 e.d /* stampa C.3.1 e E.JOHN */ 

I simboli iniziano con un carattere alfabetico o con un carattere 
speciale, ma non possono cominciare con un punto (.), con un 
punto e virgola (;) o con un due punti (:). Questi simboli posso¬ 
no essere usati come variabili, come etichette e, se non vengo¬ 
no inizializzati, possono essere anche trattati come stringhe. 

si otterrebbe Amiga Fred come output. 

I numeri 

I numeri consistono in sequenze di caratteri numerici che pos¬ 

La parte rimanente di un simbolo può contenere numeri e alcu¬ 
ni caratteri speciali. Tutte le lettere di un simbolo vengono au¬ 
tomaticamente trasformate nelle corrispondenti maiuscole 
prima dell'esecuzione. 

sono essere precedute dal segno meno o dal segno più. I nume¬ 
ri possono contenere anche il punto per rappresentare il punto 
decimale e/o E (oppure e) per rappresentare la notazione espo¬ 
nenziale. 

Quando un simbolo non viene inizializzato e non funge da eti¬ 
chetta assume il valore del proprio nome, sebbene, per espe¬ 
rienza personale, è meglio non fare uso di questa caratteristica 
del linguaggio, se non in programmi molto semplici. 

I seguenti sono tutti numeri legali in Rexx: 

1 1.0 -1.0 

2e5 2e-3 +12.34 

Un’etichetta è un simbolo terminante con un due punti (:). 

Gli operatori 

a=l /* a è una semplice variabile */ 

a=b /* b è una semplice variabile. 

Gli operatori consistono nella tipica serie di operatori dei com¬ 
puter, includendo + - < <= e così via. La serie completa e le re- 


eccetto quando non sia stata ancora lative priorità si trovano nel manuale di ARexx. 


inizializzata, nel qual caso assume 
il valore di b */ 

Tasso interessi=0. 5 /* rende i nomi delle 

variabili più leggibili */ 

#a=0 /* si possono usare alcuni simboli 

speciali per cominciare il nome 
di una variabile */ 

Cali Start /* questa è una chiamata alla 

routine etichettata come Start */ 
Start: /* etichetta della routine Start */ 

Vale la pena, comunque, menzionare due operatori speciali per 
stringhe. Il primo consiste in due barre verticali (II) e il secondo 
nel semplice carattere di spazio. 

Se eseguiamo la seguente istruzione: 

a='Hello there' 'world' 

allora a conterrà "Hello there world", ma scrivendo: 

Gli array 

a = 'Hello there'| |' world' 

Il punto (.) ha un significato speciale, in quanto viene utilizzato 
per creare simboli composti e radici. Un simbolo composto 
consiste della radice e di una o più desinenze. Supponiamo di 
avere un semplice array di elementi dallo 0 al 9 chiamato a. I 
nomi degli elementi saranno allora a.O a. 1 e così via. Possiamo 
utilizzare la variabile b per accedere a questi elementi, scriven¬ 
do a.b. Mettendo in b un valore compreso fra 0 e 9, otterremo 
il valore dell’elemento desiderato. Mettendo in b il valore 10, 
ci verrà restituito a. 10. Si possono creare anche array multidi- 
mensionali, utilizzando più desinenze come in a.b.c. 

a conterrà "Hello thereworld" (nessuno spazio fra there e 
world). 

Tutte le regole sopracitate potrebbero sembrare complesse, ma 
quando si comincia a utilizzare il linguaggio si scopre che la 
maggior parte di esse sono naturali e che viene spontaneo im¬ 
piegarle. 

L’opzione di trace 

Per dimostrare la potenza dell’opzione di trace di Rexx, inseri- 

Una radice ha solo un punto e questo deve essere l’ultimo ca¬ 
rattere del suo nome. Questa viene utilizzata per inizializzare 
tutte le possibili variabili composte che hanno la stessa radice. 
Eseguendo a.=0 si hanno degli effetti sia in a.b, sia in a.b.c. 

te il seguente programma in un file di testo (utilizzando qual¬ 
siasi editor che produca un output ASCII) e chiamatelo 
SIMPLE, ricordando che tutti i programmi Rexx devono co¬ 
minciare con un commento: 

1 1 38 | 

□ Fb 
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/* Un semplice (SIMPLE) programma Rexx */ 
Trace Value 'Off' /* disabilita il trace */ 
a=l /* assegna 1 ad a */ 

b=/* possiamo mettere un commento qui */ 

'John' 

/* assegna "John" ab*/ 
Say "Say" b a /* stampa a e b */ 

Exit 0 /* Il comando exit è uno 

dei modi per terminare 
un programma Rexx */ 

Con la versione Amiga di Rexx, avremo prima bisogno di ave¬ 
re in esecuzione il programma principale di background, chia¬ 
mato rexxmast. Una volta che questo è stato lanciato 
(scrivendo semplicemente rexxmast nel CLI) il programma 
SIMPLE può essere eseguito scrivendo: 

RX SIMPLE 

Il risultato di questo programma sarà: 

Say John 1 

Non c’è niente di difficile fino a questo punto. Adesso cambia¬ 
mo la linea di trace in questo modo: 

Trace Value 'R' /* visualizza i risultati */ 

L’output adesso sarà: 

3 *-* a=l; 

>» " 1 " 

4 *-* b= 'John'; 

>» "John" 

5 *-* ; 

6 *-* Say "Say" b a; 

>» "Say John 1" 

Say John 1 

8 *-* Exit 0; 

»> " 0 " 

I numeri sulla sinistra rappresentano il numero della linea che 
contiene le istruzioni nel file. Il simbolo *-* indica la presenza 
di una linea di istruzione. Segue l’istruzione e il simbolo »> 
che indica il risultato dell’operazione. 

Adesso cambiamo la linea di trace in questo modo: 

Trace Value 'I' /* visualizza i risultati 

intermedi */ 


L’output diventa: 

3 *-* a=l; 

>L> "1" 

4 *-* b= 'John'; 

5 * - * ; 

6 *-* Say "Say" b a; 
>V> "John" 

>V> "1" 


>0> "Say John" 
>0> "Say John 1" 
Say John 1 

8 *-* Exit 0; 

>L> "0" 


A questo punto, i commenti e gli spazi bianchi superflui sono 
stati eliminati ed è stato aggiunto il delimitatore di istruzione 
(;). Il simbolo >L> indica l’elaborazione di una stringa (L sta 
per literal). Il simbolo >V> contraddistingue il contenuto di 
una variabile e il simbolo >0> produce il risultato intermedio 
mentre l’interprete sta lavorando su due operandi alla volta. Ci 
sono molte altre opzioni di trace ma io tendo a utilizzare quelle 
sopra menzionate, o l’opzione ’ALL’ che visualizza semplice- 
mente l’intera istruzione, oppure ’OFF’ che disabilita il trace. 

Ci sono anche due caratteri speciali che possono essere utiliz¬ 
zati come prefisso per l’opzione di trace: ? e !. Il prefisso ? abi¬ 
lita o disabilita il trace interattivo. Premendo enter senza input 
viene eseguita la prossima istruzione, ma se inseriamo dei dati, 
questi vengono interpretati come un’istruzione a sé stante. 
Questo è uno strumento di debugging molto potente e perso¬ 
nalmente tendo a utilizzarlo con le opzioni di trace result (R) e 
intermediate (I). Una volta provato, dubito che vorrete mai più 
usare un interprete di qualsiasi tipo che non disponga di questo 
livello di trace. 


Il prefisso ! abilita o disabilita la funzione che blocca la spedi¬ 
zione di un comando a un programma host. Quando questa 
funzione è inserita, l’istruzione viene esaminata ma il comando 
non viene mandato al programma esterno e la speciale variabi¬ 
le di ritorno (RC) viene messa a zero. Il blocco della spedizio¬ 
ne dei comandi al programma host viene rimosso quando si 
esegue il comando di trace specificando l’opzione OFF. 

Gli assegnamenti 

Nell’ultimo programma abbiamo visto l’assegnamento di strin¬ 
ghe e di numeri. Quelli che hanno familiarità con il BASIC si 
chiederanno che fine abbia fatto il suffisso $ per le variabili 
stringa. La risposta è che non esistono più, ma l’idea di variabi¬ 
li numeriche e di stringa continua a esistere. Provate ora a digi¬ 
tare ed eseguire questo programma: 


/* Programma 2 */ 

Trace 'I' /* trace interattivo */ 

a=l /* assegna il numero 1 ad a */ 

b='l' /* assegna il carattere lab*/ 

c=a+b /* poi li somma insieme */ 

Say c /* e stampa il risultato */ 

d='2+2' /* mette in d una stringa 

non-numerica */ 


Say c+d 
Exit 0 


Il risultato sarà: 


3 *-* a=l; 
>L> "1" 

4 *-* b='1'; 
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5 *-* c=a+b; 

>V> "1" 

>V> "1" 

> 0 > " 2 " 

6 *-* Say c; 

>V> "2" 

2 

7 *-* d='2+2' ; 

8 *-* Say c+d; 

>V> "2" 

>V> "2+2" 

+++ Error 47 in line 8: Arithmetic conversion 
error 

Command returned 10/47: Arithmetic conversion 
error 

La cosa sorprendente per i programmatori BASIC è che, nono¬ 
stante b contenesse un carattere, ARexx è stato in grado di in¬ 
terpretarlo correttamente come un numero e di fare le 
conversioni necessarie alla linea 5. La stringa d non contiene, 
invece, un numero valido, quindi l’addizione di linea 8 non 
può essere fatta. Cambiando la linea 7 in questo modo: 

d='2.2' 

oppure in 

d='2e2' 

il programma funzionerà correttamente. 



>>> 

"0" 


>>> 

"HELLO WORLD" 


>» 

"i" 

8 

* — "k 

a.i = Word(invar,i+1); 


>» 

"HELLO WORLD" 


>>> 

Il 1 II 


>» 

"HELLO” 

9 

-k _ -k 

end; 

7 

k — k 

Do i = 0 to Words(invar) 


>>> 

"i" 

8 

k _ k 

a.i = Word(invar,i+1); 


»> 

"HELLO WORLD" 


>» 

"2" 


»> 

"WORLD" 

9 

k _ * 

end; 

7 

* _ * 

Do i = 0 to Words(invar) 


>» 

ii 2 1* 

11 

k _ k 

Say a. 5; 


>» 

"A. 5" 

5 



12 

k _ * 

Exit Ó; 


>» 

"0" 


La linea 6 contiene l’istruzione PULL. Questa istruzione viene 
utilizzata per ottenere dell’input dallo stack. Quando lo stack è 
vuoto, come in questo caso, leggerà una stringa dalla console. 

La linea 7 è l’inizio di un loop creato dall'istruzione do abbina¬ 
ta a end che si trova sulla linea 9. Questo uso di do-end è equi¬ 
valente alle istruzioni BASIC: 


Ancora array 

Il programma seguente esplora i simboli composti e le radici. 

/* Programma 3 */ 

Trace 'R' /* trace dei risultati */ 

Say 'Inserite alcune parole e premete enter' 
Pulì invar /* assegna l'input a INVAR */ 

Do i = 0 to Words(invar)-1 

/* loop per preparare 1'array 
a.i = Word(invar,i+1) 

/* assegna una parola a ogni 
elemento */ 

end /* termine del loop */ 

Say a. 5 
Exit 0 

Lanciamo il programma e scriviamo Hello world quando ci 
verrà richiesto. Questo sarà il risultato: 

4 *-* Say 'Inserite alcune parole e premete 
enter'; 

>» "Inserite alcune parole e premete enter" 


FOR 1=1 to N 
NEXT 

Alla linea 7 troviamo la funzione Wordsi). ARexx, come avre¬ 
te occasione di apprendere, ha molte funzioni. Questa restitui¬ 
sce il numero di parole contenute in una stringa. 

La linea 8 contiene l’assegnamento deH’array a. Dopo il loop 
do, l’elemento a.O conterrà HELLO, mentre l’elemento a. 1 
/conterrà THERE. La funzione Word!) restituisce l’ennesima 
parola di una stringa. 

La linea 11 stampa il sesto elemento dell’array a, ma avendo 
inserito solo due elementi, l’elemento 6 risulta non inizializza- 
to. In questo caso, come abbiamo già visto, le regole stabilisco¬ 
no che una variabile non inizializzata contiene il valore del 
proprio nome. Questo spiega per quale motivo è stato stampato 
A.5. 

Inserendo una nuova linea fra la numero 6 e la numero 7, chia¬ 
miamola 6bis, contenente il comando: 

a. = "" /* inizializza l'array */ 


Inserite alcune parole, poi premete enter il programma girerà correttamente. La linea 11 stamperà ades¬ 

so una linea vuota se non digitiamo la sesta parola. 

6 *-* Pulì invar; 

>» "hello WORLD" Nella prossima puntata daremo un’occhiata ad alcune altre 


7 *-* Do i = 0 to Words(invar)-1; 

istruzioni ARexx, compresa la do-end in dettaglio. 
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0 Transactor per AMIGA 


I dischi di Fred Fish - 2 


Prima guida ragionata al loro contenuto 


EDITOR DI TESTI 


95 

CYGNUSEDDEMO 


k 

DEMO DI UN TEXT EDITOR-MASSIMO FILE DA 5k 

[CYGNUSSOFT] 

59 

DME 

1.22 


EDITOR DI TESTI PER PROGRAMMATORI WYSYWYG 

[DILLON] 

74 

DME 

1.25 


EDITOR DI TESTI PER PROGRAMMATORI WISIWIG 

[DILLON] 

87 

DME 

1.27 


EDITOR DI TESTI PER PROGRAMMATORI WISIWIG 

[DILLON] 

93 

DME 

1.27 

* 

EDITOR DI TESTI PER PROGRAMMATORI WISIWIG 

[DILLON] 

113 

DME 

1.28F 

★ 

EDITOR DI TESTI PER PROGRAMMATORI WISIWIG 

[DILLON] 

134 

DME 

1.29 

* 

EDITOR DI TESTI PER PROGRAMMATORI WISIWIG 

[DILLON] 

84 

ED 


k 

SIMILE AS ED PER UNIX - EDITOR DI TESTI 

[BEATTIE] 

22 

LEMACS 

3.6 

* 

EDITOR DI TESTI 

[LAWRANCE 
(CONROY)] 

60 

MED 

2.1 


EDITA SU 36 LINEE SIMULTANEAMENTE (USARE MOUSE) 

[ROUAIX] 

2 

MICROEMACS 

2.0 

* 

VERSIONE DI EMACS TEXT ED - CARATTERISTICHE LIMITATE 

[CONROY/JONES] 

6 

MICROEMACS 

2.0 

★ 

EDITOR DI TESTI EMACS - INC SUPPORTO TASTI FUNZIONE 

[ROOSE 
(CONROY)] 

61 

MICROEMACS 

3.8B 

* 

EDITOR DI TESTI 

LAWRENCE 
(CONROY)] 

93 

MICROEMACS 

3.81 

★ 

EDITOR DI TESTI 

[LAWRENCE 
(CONROY)] 

119 

MICROEMACS 

3.9E 

★ 

EDITOR DI TESTI 

[LAWRENCE 
(CONROY)] 

23 

MICROEMACS 

30 

★ 

POTENTE EDITOR DI TESTI 


42 

MICROGNUEMACS 

1A 

k 

PICCOLO E POTENTE EDITOR DI TESTI 


131 

MICROGNUEMACS 

1B 

* 

PICCOLO,POTENTE EDITOR (MACROS E PORTA AREXX) 

[ROKICKI] 

22 

PEMACS 


k 

EDITOR DI TESTI 

[POGGIO 
(CONROY)] 

20 

83 

TED 

TEX 

0.85 


VERSIONE DEMO DELL'EDITOR DI TESTI 

VERSIONE DEMO DI UN EDITOR DI TESTI / PER PICCOLI FILES 

[HEATH] 

[ROKICKI] 

31 

TXED 

1.1 


MICROSMITH EDITOR-DEMO (MASSIMO FILE 10K) 

[HEATH] 

60 

UEDIT 

2.0 


POTENTE EDITOR DI TESTI / CONSIGLIABILE 

[STYLES] 

121 

60 

UEDIT 

UETURBO 

2.3 


EDITOR DI TESTI 

VERSIONE PER PROGRAMMATORI DI UEDIT 

[STILES] 

[ALTHOFF] 


FORMATTATORE DI TESTI 


65 

BAWK 


k 

PROCESSORE DI TESTO (ALA UNIX AWK) 


[BRODT] 

92 

BAWK 


k 

PROCESSORE DI TESTO (ALA UNIX AWK) 


[WIDEN 







(BRODT)] 

14 

DEX 


k 

ESTRAE COMMENTI DA UN FILE SORGENTE IN FORMATO NROFF 

[FISH] 

3 

FF 


k 

FORMATTATORE DI TESTO MOLTO VELOCE 


[PERMAN] 

79 

NRO 


k 

PROCESSORE ED EDITOR DI TESTO STILE ROFF 

[BROWING] 

9 

PROFF 

1.1 

k 

POTENETE FORMATTATORE TESO -RISCRITTURA 

DI ROFF PER UNIX 

[YIGIT/TRESS] 

46 

PROFFMACROS 


* 

SETS DI MACROS PER ROFF 


[ANDREWS/ 







WALKER] 

3 

ROFF 


k 

FORMATTATORE TESTO (COME LA VERSIONE DI 

SOFTWARE TOOLS) 

[ YAP ] 

128 

SED 


k 

EDITOR A SCORRIMENTO UNIX - TEXT EDITOR 


[RAYMOND] 

GIOCHI DI RICREAZIONE 




120 

AMOEBA 



CLONE DI SPACE INVADERS 


[LATENIGHT DEV] 

122 

ASTEROIDS 



GIOCO TIPO ASTEROIDS - SUONO E IMMAGINI 

SOSTITUIBILI 

[MARIANI] 

28 

BACKGAMMON 


k 

GIOCO GRAFICO DEL BACKGAMMON (ABASIC) 


[ADDISON] 

120 

BACKGAMMON 

1.0 

k 

GIOCO GRAFICO DEL BACKGAMMON 


[PFISTER] 


41 


'b 


















0 


Transactor per AMIGA 


19 

BLACKJACK 


* 

GIOCO DI CARTE DEL BLACKJACK / VERSIONE TESTO 

[PLUM HALL 






INC. ] 

50 

BREAKOUT 

1.0 


VERSIONE 3D DEL GIOCO TRADIZIONALE - CON OCCHIALI 3D 

[ KEMP ] 

13 

BRICKOUT.BAS 


* 

GIOCO BRICKOUT - USA IL MOUSE COME CONTROLLORE (ABASIC) 

[DAVISON] 

32 

CANFIELD 


* 

GIOCO DI CARTE (ABASIC) 

[ADDISON] 

96 

CHESS 

1.0 

★ 

BUON GIOCO DEGLI SCACCHI - NON AMIGA'D 

[LEIVIAN 






(STANBACK)] 

45 

CLUE 


k 

CLUEDO STILE GIOCO DA TAVOLO 

[PRYOR] 

10 

CONQUEST 

1.0 


CONTROLLO DI UNA IMPERO INTERSTELLARE 

[SHIMBO] 

24 

CONQUEST 

1.1 

* 

AVVENTURA SPAZIALE 

[SHIMBO] 

51 

COS 



RUOTA DELLA FORTUNA - (AMIGABASIC) 

[MICHEL] 

40 

COSMO 



SEMPLICE ARCADE STILE SPACE SHOOT GAME 

[HARRIS] 

28 

CRIBBAGE 


k 

GIOCO DI CARTE (ABASIC) 

[ADDISON] 

78 

CYCLES 

1.0 


ISPIRATO AL FILM TRON 

[GILMORE] 

120 

EGYPTIANRUN 

1.1 


SEMPLICE GIOCO DI CORSA E D'AZZARDO 

[HAMES] 

118 

EMPIRE 

1.0 

* 

SIMULAZIONE POLITICA,ECONOMICA E DI GUERRA PER + GIOCAT. 

[GRAY/ 






LANGSTON] 

78 

EOMS 



GIOCO DI SIMULAZIONE MERCENARIA PER ESPERTI 

[CARDENAS] 

70 

GRAVITYWARS 

1.03 


GIOCO NAVE/MISSILE CON GRAVITA' 

[BARZ] 

84 

GRAVITYWARS 

1.04 

★ 

GIOCO NAVE/MISSILE CON GRAVITA' 

[BARTZ] 

105 

GRAVITYWARS 

2.0 


GIOCO NAVE/MISSILE CON GRAVITA' 

[BARTZ] 

7 

HACK 

1.0.1 


GIOCO D'AVVENTURA HACK (DATI SORGENTI SU FISH 8) 

[TOEBES] 

32 

KLONDIKE 


* 

GIOCO DI CARTE - (AMIGABASIC) 

[ADDISON] 

63 

LARN 

12.0B 


GIOCO D'AWENTURA/LABIRINTO (COME HACK) 

[BURNETTE 






(MORGAN)] 

28 

MILESTONE 

1.0 

k 

CORSA IN AUTOMOBILE (ABASIC) 

[ADDISON] 

50 

MISSILE 

1.1 


GIOCO DIFESA MISSILE 

[MERRIMAN] 

15 

MONOPOLY 



GIOCO DA TAVOLO MONOPOLY (ABASIC) 

[ADDISON] 

28 

OTHELLO 


k 

GIOCO DELL'OTHELLO (ABASIC) 

[ADDISON] 

90 

OTHELLO 

1.0 


GIOCO DELL'OTHELLO 

[BELLEW (ROY)] 

122 

PUSHOVER 


k 

GIOCO TIPO FORZA 5 (AMIGA BASIC) 

[YOST] 

32 

PUZZLE 

1.2 


CLASSICO PUZZLE A 15 PEZZI 

[BEOGELEIN] 

38 

REVERSI 

6.1 


GIOCO DELL'OTHELLO 

[ALMUDEVAR] 

106 

RISTINOLLA 

1.0 


VERSIONE FINALE DI GO-MOKU 

[PIHLAJAMAKI] 

82 

ROCKET 



MISSILE CHE ATTERRA SU UNA FINESTRA 

[DA SILVA] 

85 

ROCKET 


k 

MISSILE CHE ATTERRA SU UNA FINESTRA 

[DA SILVA] 

55 

SHANGHAIDEMO 



GIOCO DELL'ACTIVISION BASATO SU MAHJONG - DEMO 

[ACTIVISION] 

103 

SOL 


k 

SOLITARIO 

[GOODENOUGH/ 






SWANK] 

10 

TREK73 


k 

GIOCO DI STAR TREK - BASATO SUL TESTO 


35 

TRICLOPS 

1.6 


GIOCO SPAZIALE 3D 

[ GEODESICPUBL] 

36 

TUNNELVISION 


*L 

LABIRINTO - CON VEDUTE 3D DALL'INTERNO IN PROSPETTIVA 

[ADDISON] 

100 

WBLANDER 

2.1 


SEMPLICE ATTERRAGGIO SULLA LUNA 

[DA SILVA] 

114 

WLANDER 

2.1 

k 

SEMPLICE ATTERRAGGIO SULLA LUNA - CON SORPRESA 

[DA SILVA/ 


« 




LEHENBAUER] 

10 

YACHTC 


k 

GIOCO DELLO YAHTZEE DICE 

[LEEMON] 

LETTORE DI TESTI 




60 

BLITZ 

1.0 


LETTORE DI FILES DI TESTO VELOCE-ATTIVABILE DA HOY-KEY 

[HAUGEN] 

34 

LESS 


k 

LETTORE DI TESTO CON MOVIMENTI AVANTI/DIETRO 

[NUDELMAN/ 






LEIVIAN] 

74 

LESS 

1.1 

k 

LETTORE DI FILES DI TESTO - MUOVE AVANTI/DIETRO 

[LEIVIAN 






(NUDELMAN] 

36 

LEX 



COMPUTA INDICI LEGGIBILI DI FILES TESTO 

[SULLIVAN] 

MONITOR PER IL SISTEMA 


40 

AMIGAMONITOR 

0.21 


MOSTRA FILES APERTI,MEMORIA,TASK ECO IN TEMPO REALE 

[VORIS] 

70 

AMIGAMONITOR 

1.13 


MOSTRA FILES APERTI,MEMORIA,TASK ECO IN TEMPO REALE 

[VORIS] 

111 

AMYLOAD 


k 

MONITOR GRAFICO DI CPU,BLITTER E USO MEMORIA 

[KELLY] 

5 

FREEMAP 


k 

VISUALIZZA DIAGRAMMI DELLA MEMORIA LIBERA 

[MIKAL] 


111 GAUGE 
1 GFXMEM 
14 GFXMEM 
54 LAV 
123 LIBS 
108 MONIDCMP 
69 MONPROC 
79 MONPROC 

69 SB 


0.4 

0.5 


1.0 
1.1 


1.0 


VISUALIZZA LA MEMORIA CON BARRE GRAFICHE VERTICALI 
MOSTRA L'USO DELLA MEMORIA DI AMIGA GRAFICAMENTE 
MOSTRA L'USO DELLA MEMORIA DI AMIGA GRAFICAMENTE 
MOSTRA NUM. DEI TASK IN CODA D'ESECUZIONE NEL TITLE BAR 
VISUALIZZA LISTA LIBRERIE E DETTAGLI DISPONIBILE 
MONITOR INTUIMESSAGES PASSANDO ATTRAVERSO IDCMP 
MONITOR AMIGADOS PROCESSI PACCHETTI ATTIVI 
MONITOR PACCHETTI ATTIVI 

SCORRE LE STRUTTURE SISTEMA 


[DA SILVA] 
[MAMAKOS] 
[MAMAKOS] 
[ROCKIIDGE] 

[CERVONE] 
[LINSAY] 
[CERVONE 
(LINDSAY)] 
[SULLIVAN/ 
ZAMARA] 


BU 
















H Transactor per AMIGA 


58 SYSMON 
74 TDEBUG 
7 9 WHO 
73 XPLOR 


1.00 


MONITOR GRAFICO DI VARI PARAMETRI DI SISTEMA 
MONITOR DEVICE IO REQUEST PER DEBUGGING 
LISTA DEI TASK NELLA CODA PRONTI/ATTESA 
MOSTRA SOMMARIAMENTE TUTTE LISTE SISTEMA DA EXECBASE 


PROGRAMMI DI VARIO TIPO 


33 

3DSTARS 

15 

BLOBS 

71 

BLOCKS 

127 

BOUNCE 

126 

DANCE1 

126 

DANCE2 

15 

DAZZLE 

89 

DEMOLITION 

66 

DK 

69 

DK 

1 

DOTTY 

105 

DRUNKENMOUSE 

66 

FLIP 

52 

HAMPOLY 

54 

ING 

46 

JIVE 

41 

LINES 

66 

MELT 

9 

MOIRE 

87 

MINCHINSQ 

137 

MUNCHO 

66 

NART 

90 

NEWDEMOS 

33 

OING 

18 

PIGLATIN 

49 

POLYGON 

90 

RAINBENCH 

58 

RAINBOW 

59 

ROBOTROFF 

82 

SAND 

81 

SCAT 

90 

SIZZLERS 

50 

SIZZLERS 

81 

SMOSH 

9 

SPARKS 

33 

SPROING 

33 

STARS 

118 

STARS 

43 

STEMULATOR 

81 

TARGET 

54 

TILT 

113 

TILT 

32 

TRAILS 

84 

VIACOM 

112 

VIACOM 

112 

WAVEBENCH 

36 

YABOING 

136 

YABOING 


1.0 
1.1 


SHELL 


1.7. 

1 . 0 . 


1.23 


II 


CAMPO DI STELLE 3D (CI VOGLIONO OCCHIALI ROSSI/BLU 3D) 
DISEGNA LINEE VAGANTI COLORATE 

VISUALIZZA QUADRATI COLORATI IN MOVIMENTO (COME LINEE) 
CREA PUNTI CHE RIMBALZANO ATTORNO E MULTIPLI 

MOVIMENTO POLIGONI 

MOVIMENTO POLIGONI IN MODO HAM 

DISEGNA PUNTI CASUALI,MA CON 8-PIEGHE SIMMETRICHE 

PUNTO CHE RIMBALZA ATTORNO SCHERMO-MANGIANDOSI NEL PERC. 

VISUALIZZA LENTA DISINTEGRAZIONE 

VISUALIZZA LENTA DISINTEGRAZIONE 

SORGENTE PER DEMO SUL DISCO DEL WORKBENCH 

FA MUOVERE IL PUNTATORE DEL MOUSE COME SE TU HAI BEVUTO 

GIRA LO SCHERMO DALL'ALTO AL BASSO 

DISEGNA POLIGONI MULTIPLI - IN MODO HAM 

FA RIMBALZARE LE WINDOW ATTORNO ALLO SCHERMO 

SCRIVE IN TESTO CHIARO E PRODUCE JIVE TALK 

DISEGNA LINEE CHE SI MUOVONO 

SCHERMO CHE SI SCIOGLIE VERSO IL BASSO 

CREA DISEGNI UTILIZZANDO ALGORITMI PREDEFINITI 

GENERA QUADRATI BASATI SU PATTERN DIPENDENTI DAI PRECED. 

GULP QUANDO DISCO E' INSERITO(E YUCH QUANDO E' RIMOSSO) 

MOVIMENTO DI LINEE GRAFICHE 

NUOVA VERSIONE LINEE E QUADRATI-UTILIZZA MENO TEMPO CPU 
WINDOW PIENE DI PALLE RIMBALZANTI 
TRADUCE DA INGLESE A "LATINO GREZZO" 

DISEGNA ROMBI E CERCHI CONCENTRICI SOVRAPPONENDOLI 
FAI CICLARE I COLORI DEL WORKBENCH 

ASSEGNA AL BACKGROUND COLORI SIMILE A QUELLI DI MARAUDER 
ROBOT CHE SEGUE IL PUNTATORE DEL MOUSE 

GRANELLI DI SABBIA CHE SEGUONO PUNTATORE QUANDO SI MUOVE 

VISUALIZZA HACK-ATTIVA WINDOW SOTTO PUNTATORE 

GENERA UNA SERIE DI LINEE IN MOVIMENTO DEMO 

GENERA UNA SERIE DI LINEE IN MOVIMENTO DEMO 

VISUALIZZA HACK-CI VUOLE FILE IFF PER VEDERE COSA ACCADE 

LINEE CHE CAMMINANO-SEMPLICE DEMO GRAFICO 

PALLE RIMBALZANTI-COLLISIONI COL BORDO( + SUONO) 

VISUALIZZA UNO SCHERMO PIENO DI STELLE 

NAVE SPAZIALE CHE VIAGGIA ATTRAVERSO UN CAMPO STELLATO 
SCHERMO E RUMORI IN STILE ST QUANDO FAI QUALCOSA 
TRASFORMA PUNTATORE MOUSE IN MIRINO CON UN COLPO FUCILE! 
INCLINA LO SCHERMO IN SU DA UN LATO 
INCLINA LO SCHRMO IN SU DA UN LATO 

LASCIA UNA SCIA DIETRO IL MOUSE 
VISUALIZZA HACK-CREA UNA FIGURA RUMOROSA 
VISUALIZZA HACK-CREA UNA FIGURA RUMOROSA 

INCRESPA LO SCHERMO DEL WORKBENCH 

AFFERRA SPRITES CON IL MOUSE (SCOPRE COLLISIONI DEMO) 
AFFERRA SPRITES CON IL MOUSE (SCOPRE COLLISIONI DEMO) 


[KIVOLOVITS] 

[DILLON] 

[MUSSER] 

[PHILIPS] 


[SCHWAB] 

[ENGELBRITE] 

[WALKER] 

[HANSEL/ 

HANSEL] 

[OLSEN] 

[OLSEN] 

[ENGELBRITE] 

[KIRYMIS] 

[HANDEL] 

[HANDEL] 

[LUCK] 

[LIVSHITS] 

[BERRÒ] 

[HOLSEN] 

[SCHWAB] 

[JATKOWSKI] 
[COY] 

[BALLANTYNE] 

[SCHWAB] 

[WERTH] 

[SCHWAB] 
[KOREN] 

[SCHWAB] 
[CLEMENTI 
[GINTZ] 
[HODGSON] 

[HODGSON] 

[SCHWAB] 

[VAUGHAN] 

[EPLEY] 

[EPLEY] 

[ORRIS] 

[BALLANRYNE] 

[SCHWAB] 

[SCHWAB] 

[ORRIS] 

[ADDISON] 

[SCHWAB] 

[SHAUB 

(SCHWAB)] 

[BIELAK] 

[SCHWAB] 

[NESBITT 

(SCHWAB)] 

[NESBITT] 


18 

ASH 



PREREALIZZAZIONE SHELL-STORI, 

LOOPS,SOSTITUZIONI 

[SMITH] 

24 

CSH 

i. i 

* 

SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DILLON] 

36 

CSH 

2.01A 

* 

SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DILLON] 

41 

CSH 

2.03 


SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DILLON] 

48 

CSH 

2.04 

* 

SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DILLON] 

48 

CSH 

2.04M 

•k 

SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DREW 
(DILLON)] 

55 

CSH 

2.05M 

* 

SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DREW (FRLOM 
DILLOM)] 

85 

CSH 

2.06M 

* 

SOSTITUZIONE 

SHELL 

STILE 

CSH 

PER 

CLI 

[DREW 
(DILLON)] 


JK. 















0 Transactor per AMIGA 


107 

CSH 

2.07M 

* 

SOSTITUZIONE SHELL STILE CSH PER CLI 

[DREW 
(DILLON)] 

70 

JOBS 

2.1 


SVILUPPO ALTERNATIVO PER WB E CLI 

[SAWAYA] 

38 

JSH 


* 

SEMPLICI COMANDI INTERPRETE LINEA 

[KENT] 

4 

MYCLI 


k 

SOSTITUZIONE CLI 

[SCHWARZ] 

14 

SHELL 

1.0 

k 

SOSTITUZIONE SHELL STILE CSH PER CLI 

[DILLON] 

SISTEMA 





53 

ARP 


k 

PROGETTO SOSTITUZIONE DEI COMANDI AMIGADOS 


123 

ARP 

1.0 


PROGETTO SOSTITUZIONE AMIGADOS /VERSIONE PIU' AGGIORNATA 


87 

ID-HANDLER 

1.0 

* 

DEVICE HANDLER AMIGADOS CON IDENTIFICATORI UNICI 

[PUCKETT] 

SPREADSHEET 





104 

ANALYTICALC 


k 

SPREADSHEET A PIENE CARATTERISTICHE 

[EVERHART] 

36 

ve 

1.0 


VISICALC COME SPREADSHEET 

[HARDIE 
(GOSLING)] 

53 

ve 

1.1 


VISICALC COME SPREADSHEET 

[BOND 

(GOSLING)] 

TERMINALI PER COMUNICAZIONI 


98 

ACCESS 

0.18 


80X25 / XMODEM / WXMODEM / MULTICOLORE 

[YOUNG (JAMES) 

40 

AHOST 

0.9 


EMULATORE DI TERMINALE ANSI 

[WILHITE/ 

JONES] 

82 

AMICTERM 

.50 


80X25 / X/WX/ZMODEM 

[SALAS/KIRK 
(JAMES)] 

18 

AMIGADISPLAY 


k 

80X24 / ASCI DOWNLOAD 

[WOODS 
(MOUNIER)] 

1 

AMIGATERM 


k 

77X23 / XMODEM S TRASFERIMENTO ASCII 

[MOUNIER] 

12 

ARGOTERM 

0.20 

k 

77X23 / XMODEM S TRASFERIMENTO ASCII 

[SAN] 

26 

C-KERMIT 


k 

TERMINALE VIRTUALE KERMIT & TRASFERIMENTO FILE 

[CERVONE 
(MANY)] 

48 

COMM 

1.30 


EMULATORE VT100 

[JAMES] 

67 

COMM 

1.33 


EMULATORE VT100 

[JAMES] 

71 

COMM 

1.34 


EMULATORE VT100 

[JAMES] 

75 

COMM 

1.34 

k 

EMULATORE VT100 

[JAMES] 

40 

DG210 



EMULATORE DI DATA GENERAL D-210 

[LENZ] 

73 

DTERM 

1.10 


TEMINALE / XMODEM / KEY & MAPPA CARATTERI 

[DILLON] 

60 

HANDSHAKE 

1.20A 


COMPLETO EMULATORE V752 / VT100 / VT102 

[HEBERFELLNER] 

4 

KERMIT 

1.1 

k 

VECCHIA VERSIONE DI KERMIT 


14 

PDTERM 

1.21 

k 

80X25 TERMINALE VT100 / ANSI / NON TRASFERISCE 

[MCLNERNY] 

20 

SPEECHTERM 


* 

TERMINALE ANSI CON XMODEM. / SINTESI VOCALE & GRAFICI 

[KOUTSOFIOS] 

12 

STARTERM 

1.1 


TERMINALE CON ASCII / XMODEM / TASTI FUNZIONE 

[NANGANO/ 

PLEGGE] 

30 

STARTERM 

3.0 


TERMINALE / TRASFERIMENTO XMODEM 

[NANGANO] 

108 

TEK 

2.65 

k 

EMULATORE VT100 & TEKTRONIX 4010/4014 

[GIORDANO/ 

WHELAN] 

33 

TERMPLUS 

2.1 

k 

RISCRITTURA DI AMIGATERM 

[RAKOSKY 
(MOUNIER)] 

52 

TEX4010 

2.1 

k 

EMULATORE TEK 4010 

[WHELAN 
(MOUNIER)] 

29 

VT100 

1.0 

k 

EMULATORE VT100 / KERMIT & XMODEM 

[WECKER 
(MOUNIER)] 

33 

VT100 

2.0 

k 

EMULATORE VT100 / KERMIT & XMODEM 

[WECKER] 

36 

VT100 

2.2 

k 

EMULATORE VT100 / KERMIT & XMODEM 

[WECKER] 

41 

VT100 

2.3 

* 

EMULATORE VT100 / KERMIT & XMODEM 

[WECKER] 

47 

VT100 

2.4 

k 

EMULATORE VT100 / KERMIT & XMODEM 

[WECKER 
(MOUNIER)] 

55 

VT100 

2.6 

k 

EMULATORE VT100 / KERMIT & XMODEM 

[WECKER 
(MOUNIER)] 

138 

VT100 

2.6 

k 

EMULATORE VT100 / KERMIT S XMODEM 

[BARSHINGER 
(WECKER)] 

114 

VT100 

2.7 

k 

EMULATORE VT100 / KERMIT S XMODEM 

[SUMRALL 
(WECKER)] 

138 

VT100 

2.8 

k 

EMULATORE VT100 / KERMIT & XMODEM 

[SUMRALL 
(WECKER) ] 
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perfino una polizza assicurativa! 

E tutto a prezzi esclusivi. Con la 
nuova, fantastica Jackson Card '90 
anche questo è possibile. 

Grazie a un accordo esclusivo, 
infatti, il titolare Jackson Card '90 ha 
diritto a uno sconto speciale presso 
tantissimi esercizi convenzionati*: 
American Contourella, Coeco, 
Commodore, Galtrucco, GBC, Jolly 
Hotels, Misco, SAI, Salmoiraghi 
Viganò e Singer. 

Ma i vantaggi continuano. La nuova 
Jackson Card '90, offre anche: 

■ sconto speciale del 10% 
sull'acquisto di libri Jackson; 

■ invio gratuito della rivista Jackson 
Preview Magazine per tutto l’anno; 

■ invio gratuito del catalogo libri 
Jackson; 

■ speciale buono da 15.000 lire sul 
primo ordine di libri Jackson 
effettuato per corrispondenza 
direttamente presso l'editore, e 
negli stand Jackson in tutte le fiere 
specializzate. 

E avere Jackson Card '90 é facile: 
basta abbonarsi o rinnovare il 
proprio abbonamento a una delle 
riviste del Gruppo Editoriale 
Jackson, acquistare libri Jackson per 
almeno 100.000 lire nelle librerie 
e computershop convenzionati 
in tutta Italia 
o ordinarli 
direttamente 
QjTackson dall'editore. 

Jackson Card '90: nuova, più 
ricca, sempre più preziosa. 

* Tutti gli indirizzi sono pubblicati su Jackson 
Preview Magazine. 


Un abito firmato, 
una vacanza indimenticabile. 
Uno stereo tutto nuovo, 
un computer o l'ultimo 
modello di tv color 


Salmoiraghi Vigano 


SINGER 


E H Scocco 

yj JOLLY ©HO! 


Commodore fGltC/ 


JOLLY ©HOTELS GALTRUCCO ADISCO 


/a 

V CI 


AMERICAN 

CONTOURELLA 

CLUB OEI SEMPRE IN FORMA 
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Indirizzamento indiretto da registro 


Accedere alle strutture dati in assembly è facile come in C! 


di Amanda Jones 

Una gran parte del sistema operativo di Amiga si basa su rag¬ 
gruppamenti di dati (strutture) collegati fra di loro da puntatori. 
Il linguaggio C si presta molto bene alla manipolazione di que¬ 
ste complesse strutture dati, ma anche il microprocessore 
68000 è particolarmente portato per effettuare questo tipo di 
lavoro. È un fatto abbastanza sorprendente, ma il codice neces¬ 
sario per accedere ai campi dati, contenuti al l'interno di agglo¬ 
merati di variabili, come le strutture del C, non è più difficile 
da scrivere in assembly piuttosto che in C. 

Le definizioni e i flag utilizzati dai programmatori C hanno 
delle controparti nelle definizioni che troviamo nei file include 
(,i) di Amiga. Le variabili complesse, definite come strutture 
nei file header (.h) del C, hanno degli equivalenti in questi file 
include, in modo che ogni membro di una struttura sia descritto 
in modo unico da un nome e da un offset numerico rispetto a 
un indirizzo di base. Questi offset sono fomiti per permettere al 
programmatore assembly di usare un modo di indirizzamento 
del 68000 conosciuto come indiretto da registro con spiazza¬ 
mento (address register indirect with displacement). 

Una struttura tipica 

La maniera più semplice per descrivere questo modo di indiriz¬ 
zamento consiste nel vedere un esempio, che nel nostro caso si 
basa sulla struttura IntuiMessage. 

Le strutture IntuiMessage sono il tramite per lo scambio di 
pacchetti informativi da e per le porte IDCMP delle finestre. 
Sono costituite da una struttura Message dell'Exec e da una 
parte di estensione (i cui dettagli sono fomiti nel file intuition .h 
e nel manuale di Intuition ): 

struct IntuiMessage { 


struct 

Message 

ExecMessage; 

ULONG 


Class; 

USHORT 


Code; 

USHORT 


Qualifier; 

APTR 


IAddress; 

SHORT 


MouseX, MouseY; 

ULONG 


Seconds, Micros; 

struct 

Window 

*IDCMPWindow; 


struct IntuiMessage *SpecialLink; 
} 


Se elenchiamo il numero di byte che ogni campo di questa 
struttura occupa, ecco cosa troviamo: 


Byte 

Nome del campo 

20 

ExecMessage 

4 

Class 

2 

Code 

2 

Qualifier 

4 

IAddress 

2 

MouseX 

2 

MouseY 

4 

Seconds 

4 

Micros 

4 

*IDCMPWindow 

4 

*SpecialLink 

Le dimensioni 

di questi campi possono essere utilizzate per 

creare una tabella di valori espressi in byte, che mostri quanto 
lontano dobbiamo spostarci dall’inizio di una struttura Intui- 
Message per trovare un determinato campo. Il risultato sarà 
una collezione di offset (spiazzamenti) relativi alla base della 
struttura IntuiMessage: 

Offset 

Nome del campo 

0 

ExecMessage 

20 

Class 

22 

Code 

24 

Qualifier 

28 

IAddress 

30 

MouseX 

32 

MouseY 

36 

Seconds 

40 

Micros 

44 

*IDCMPWindow 

48 

*SpecialLink 


Fortunatamente non è necessario calcolare questi offset in 
quanto sono già presenti negli appropriati file include. 
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I nomi dei campi di una struttura, in assembly, hanno un prefis¬ 
so aggiunto rispetto ai corrispondenti usati nel C. Questo pre¬ 
fisso si riferisce al nome della struttura che li contiene nel C ed 
è stato aggiunto per evitare casi di omonimia. I nomi dei campi 
della struttura IntuiMessage, che troveremo neH’appropriato fi¬ 
le include, sono precisamente questi: 

Offset Nome del campo (file .i) 

0 im_ExecMessage 

20 im_Class 

22 im_Code 

24 im_Qualifier 

28 im_IAddress 

30 im_MouseX 

32 im_MouseY 

36 im_Seconds 

40 im_Micros 

44 im_IDCMPWindow 

48 im_SpecialLink 

Poiché tutti i calcoli relativi agli offset sono stati già fatti per 
noi, tutto quello che ci rimane da fare è vedere come si usano. 

Indirizzamento indiretto 

L’indirizzamento indiretto implica che, invece di specificare 
un indirizzo, si specifica la locazione di questo indirizzo. Il 
processore 68000 può usare solo i registri indirizzi per calcola¬ 
re l’indirizzo indiretto, da cui il nome indiretto da registro. 

Vediamo, per prima cosa, un esempio ordinario di indirizza¬ 
mento indiretto da registro. L’istruzione: 

move.1 (aO),d2 

utilizza l’indirizzamento indiretto da registro per specificare la 
locazione dell’operando sorgente; in sostanza dice che il dato 
deve essere letto dalla locazione il cui indirizzo è contenuto nel 


move.w im_Class(aO), class 

Quali sono le differenze con la versione C dello stesso codice? 
Ebbene, se message è un puntatore alla struttura IntuiMessage, 
useremo gli operatori = e -> per ottenere lo stesso risultato: 

qualifier = message->Qualifier; 
code = message->Code; 
class = message->Class; 

Vediamo ancora dell’altro codice che dovrebbe esserci familia¬ 
re: la combinazione Wait(), GetMsgO, leggi i dati e Re- 
plyMsgO che serve a tenere sotto controllo il traffico di una 
porta IDCMP. 


Prima la versione C: 


Wait(bitmask) , 


GetMsg(message); 


/* aspetta fino a quando */ 
/* non succede qualcosa */ 
/* leggi il messaggio */ 


class = message->Class; 
code = message->Code; 
MouseX= message->MouseX; 
MouseY= message->MouseY; 


/* leggi i dati */ 


ReplyMsg(message) 


/* rispondi al messaggio */ 


In assembly adottiamo esattamente lo stesso tipo di approccio, 
ma dobbiamo aderire alla convenzione d’uso dei registri, usata 
dalle routine di sistema. 

La funzione Wait ha bisogno che gli venga fornito un bit-mask 
nel registro DO, mentre GetMsg e ReplyMsg hanno bisogno di 
trovare in A0 l’indirizzo della porta. Incidentalmente, CALLE- 
XEC è la macro che serve a chiamare le routine della libreria 
Exec, presente nei file include di Amiga. Se mettiamo tutto 
quanto insieme, otteniamo il seguente codice assembly: 


registro A0 e poi deve essere copiato nel registro D2. 

move.1 

bitmask,dO 



CALLEXEC 

Wait 

/aspetta fino a quando non 

Adesso vediamo quello che ci serve per gestire le strutture dati 



/succede qualcosa 

in assembly. Il 68000 ci permette di specificare un valore di 

move.1 

port,aO 

/indirizzo porta in A0 

spiazzamento nell’istruzione appena vista: 





CALLEXEC 

GetMsg 

/prendi il puntatore al 

move.l im Class(aO),d2 



/messaggio 


move.1 

dO, aO 

/copialo in A0 

Se nel registro A0 è stato messo il puntatore a una struttura In- 




tuiMessage (o, detto in altre parole, se A0 contiene l’indirizzo 

move.1 

im Class(aO), class ; leggi i dati 

di una struttura IntuiMessage), allora la precedente istruzione 

move.w 

im Code(aO) 

, code 

legge il dato dal campo im_Class di quella struttura IntuiMes- 

move.w 

im_MouseX(aO), mouseX 

sage e lo copia nel registro D2. 

move.w 

im MouseY(aO), mouseY 

Avremmo potuto, altrettanto facilmente, copiare il dato in 

CALLEXEC 

ReplyMsg 

/rispondi al messaggio 


qualche altra zona di memoria. Per esempio, per spostare dei 
dati in certe variabili chiamate qualifier, code e class, userem¬ 
mo l’istruzione MOVE: 


im_Qualifier(aO), 
im Code(a0) / code 


qualifier 


Non penso che in termini di complessità ci sia una gran diffe¬ 
renza fra le due versioni. Esiste, naturalmente, una zona nella 
quale noterete una differenza fra il C e l’assembly: il vostro 
portafoglio. Gli assembler per il 68000 sono parecchio più eco¬ 
nomici dei compilatori C. 


jzh. 
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Cambiamenti nel Disk Filing System 


Cosa c è veramente di nuovo nel Fast Filing System? 


di Betty Clay 

Siamo tutti a conoscenza dell’esistenza del nuovo Fast Filing 
System; appaiono ovunque prove e paragoni fra la sua velocità 
e quella del vecchio sistema nelle quali, fatta eccezione per il 
floppy disk, il nuovo sistema risulta l'incontrastato vincitore. 

Per l'utente medio del filing System queste informazioni sono 
sufficienti. Funziona. E più veloce. 'Via il vecchio, sotto col 
nuovo'. Alcune persone arrivano addirittura a utilizzare il nuo¬ 
vo sistema anche su floppy, uso per il quale non era stato pre¬ 
visto, al quale si presta senza garantire sufficiente sicurezza e 
che, oltretutto, non risulta nemmeno più veloce dell'altro. 

Nutrendo una grande curiosità nei confronti dei filing System, 
ho voluto vedere cosa c’era esattamente in questo FFS. Quan¬ 
do ci sono dei cambiamenti, voglio sapere esattamente in cosa 
consistono e in che maniera influenzano i miei dati. Se decido 
di leggere il settore di un disco con un disk editor, voglio sape¬ 
re quali dati fanno parte delle informazioni di sistema e quali 
fanno parte del mio file. 

Il fatto che ci sia un nuovo filing System implica che siano sta¬ 
te apportate delle modifiche rispetto alle informazioni di siste¬ 
ma trattate negli articoli precedenti. Questo articolo si 
preoccupa principalmente di trovare queste modifiche, accom¬ 
pagnandone l'analisi con una quantità sufficiente di informa¬ 
zioni generali che lo rendono leggibile anche a coloro che non 
hanno speso molto tempo girovagando per i settori di un disco. 

Non avendo un hard disk su cui provare il FFS e non volendolo 
adattare ai floppy, per i quali non è raccomandato, ho utilizzato 
il RAM disk recuperabile della Commodore, contenuto nel di¬ 
sco Workbench 1.3 (RAD:). Ho selezionato 80 cilindri nella 
Mountlist, quindi l’ho attivato usando il comando MOUNT e 
Fho formattato con il FFS, usandolo per questo studio. 

Che tipo di disco sono? 

La prima cosa che il sistema legge da un disco, o dalla partizio¬ 
ne di un hard disk, è il boot block. Questo contiene una long 
word che identifica il disco come disco DOS e, su floppy, po¬ 
trebbe essere seguita dal programma necessario per fare il boot 
del sistema. Qui è disponibile una quantità di spazio considere¬ 
vole: due settori da 512 byte ognuno, meno i 32 bit che identi¬ 
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ficano il tipo di DOS. Se il disco è stato appena formattato e 
installato, solo pochi di questi byte risultano utilizzati. Quelli 
rimanenti sono saltuariamente utilizzati per memorizzarvi delle 
protezioni da parte di molti sviluppatori software e per memo¬ 
rizzarvi diversi virus da parte di gente con la mente meno co¬ 
struttiva. 

Gli utilizzatori di hard disk sono stati, nella maggior parte dei 
casi, liberi dalle preoccupazioni riguardanti i virus del boot 
block, perché è il driver dell'hard disk che si preoccupa di ef¬ 
fettuare il boot. Dell’intero boot block viene, quindi, usato solo 
l'identificatore di 32 bit. Se questo numero di identificazione 
viene alterato, il sistema provvederà a informarci che questo 
non è un disco DOS valido. Rimettere a posto questo identifi¬ 
catore è un buon punto di partenza nella serie di operazioni da 
effettuare per recuperare il contenuto di un disco. 

Per quanto riguarda i boot block, l'unica differenza notata fra i 
due filing System consiste nell'ultimo byte della long word di 
identificazione: S444F5300 per il vecchio, S444F5301 per il 
nuovo. Questi numeri vengono tradotti nei corrispondenti ca¬ 
ratteri ASCII DOSO e DOSI (dove 0 e 1 non sono caratteri 
ASCII, ma byte di quel valore; l'equivalente di CHR$(0) e 
CHR$(1)). 

Quando il sistema legge questa long word, sa quale dei due fi¬ 
ling System utilizzare; se non trova nessuno dei due in quella 
posizione, visualizza il requester ’Not a DOS disk'. In realtà, è 
stato possibile recuperare l'intero contenuto di alcune partizio¬ 
ni di hard disk, semplicemente mettendo a posto il valore di 
quella singola long word. 

Ecco quello che ho trovato nei due boot block di un disco, for¬ 
mattato con il vecchio filing System, quando li ho esaminati 
con il programma DiskED. A questo punto devo dire che prefe¬ 
risco di gran lunga DiskED per questo tipo di studio, dal mo¬ 
mento che individua chiaramente la posizione di ciascun 
oggetto, ma che comunque la Commodore avrebbe dovuto rifi¬ 
nirlo un po' e renderlo disponibile a un'audience più generale. 

# sx ; visualizza in esadecimale 

00000000 
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# g 0 

Block 0 read 


; leggi il primo boot block 
(cyl 0, sur 0, sec 0) 


# t 0 10 

0: 444F5300 

1: C0200F19 

2: 00000370 

3: 43FA0018 

4 : 4EAEFFA0 
5: 4A80670A 

6: 20402068 

7: 00167000 

8: 4E7570FF 

9: 60FA646F 

10: 732E6C69 


; stampa prime 10 long word 


La struttura RootBlock, così come le altre strutture che riguar¬ 
dano i dischi, è stampata in fondo a questo articolo. 

Durante il boot, il sistema controlla il boot block e quindi la di¬ 
rectory root. La sequenza di boot da disco dice al file System 
dove trovare la radice, quindi il driver di un hard disk dovrà fa¬ 
re altrettanto. 

Nella directory root di entrambi i sistemi, i primi sei slot (cia¬ 
scuno di 32 bit) contengono informazioni di sistema: il tipo di 
blocco (cono, settore singolo), due slot inutilizzati, le dimen¬ 
sioni della hash table (72 slot in un settore di 512 byte), uno 
slot riservato per usi futuri e uno contenente il checksum. 

Questa parte è seguita da una tabella di settantadue slot (32 bit 
ognuno) che contiene i numeri dei settori nei quali troveremo 
le directory dell’utente o intestazioni di file (file header). 


Ecco invece come si presenta l’FFS: 


# sx 


; visualizza in esadecimale 


00000260 


# g 0 

Block 0 


# t 0 10 
0 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 


; leggi il primo boot block 
read (cyl 0, sur 0, sec 0) 


0 

444F5301 

; stampa 

prime 10 long word 

444F5302 

; diversi 

perché RAD: non 

444F5303 

444F5304 

4 4 4F5305 

444F5306 

444F5307 

444F5308 

444F5309 

444F530A 

; è stato 

'installato'. 


444F530B 


I tentativi di eseguire un INSTALL del RAD: sono andati a 
vuoto, quindi il boot block di questo esempio non contiene la 
sequenza di boot. La chiave, comunque, sta nel primo numero 
di ciascuna sequenza. 

Alla radice di tutto 


Il software di sistema è scritto in modo da poter continuare a 
funzionare se le dimensioni dei blocchi dovessero essere cam¬ 
biate, ma nessun cambiamento in questo senso è stato finora 
annunciato. C’è, comunque, qualche indizio che fa pensare che 
qualche cambiamento possa essere fatto nella versione 1.4 del 
Kickstart, quindi i programmatori devono essere consapevoli 
del fatto che potremmo non avere per sempre questo standard 
di 512 byte per le dimensioni dei blocchi. Il software che si in¬ 
tende scrivere dovrebbe essere in grado di gestire anche altre 
dimensioni. La maggior parte del software non si deve preoc¬ 
cupare delle dimensioni dei settori di un disco, ma coloro che 
scrivono programmi per il recupero di dischi danneggiati o 
disk editor dovranno prevedere eventuali modifiche che po¬ 
trebbero essere introdotte (e che probabilmente saranno intro¬ 
dotte) nelle future versioni del sistema operativo. 

Benché la hash table non sia oggetto di particolare interesse nel 
corso di questo articolo, vale la pena notare che i valori di hash 
devono attualmente ricadere fra i valori 6 e 77 compresi. Il va¬ 
lore più basso è sei perché le informazioni di sistema occupano 
gli slot dallo zero al cinque. 

L’algoritmo usato per calcolare il valore di hash è apparso ri¬ 
petutamente in messaggi scritti da dipendenti Commodore: 


Hash(name) 

unsigned char *name; 
{ 

int vai,i; 


La directory root (radice) è la stessa, sia nel vecchio che nel 
nuovo sistema, o almeno così sembra a una prima occhiata. 
Beh, non è esattamente così. 

Il blocco root è la chiave dell’intero disco in entrambi i sistemi. 
Esso è il settore centrale in ogni tipo di disco o partizione, ren¬ 
dendo così il tempo di seek (spostamento da una traccia all’al¬ 
tra) il più piccolo possibile per ogni settore. Gli altri blocchi 
del disco vengono raggiunti passando prima attraverso questo 
blocco e, se questo si danneggia, bisogna prendere misure dra¬ 
stiche per recuperarlo, oppure rinunciare al contenuto del di¬ 
sco. 


vai = (int)*name++; 

for (i = 0; i < vai; i++) 

val=((val*13) + (int)toupper(*name++))&0x7ff ; 
return (vai % 72); 

} 

Ogni possible nome di file uscirà da questo algoritmo con un 
valore compreso in questo intervallo. Il numero del blocco hea¬ 
der di questo file verrà messo nello slot corrispondente a que¬ 
sto valore di hash. Nel caso di due file con lo stesso valore di 
hash. si ricorre a una catena di hash (hash chain). 
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Dopo la hash table c’è una long word che contiene i flag del 
bitmap, il cui valore dovrebbe essere -1 oppure 0. 

Quando viene terminato l'aggiomamento del bitmap, questo 
flag viene messo a -1 ; se il sistema trova in questo posto uno 0 
durante il boot, verrà invocato il disk-validator per ricostruire il 
bitmap. Questa operazione può richiedere un tempo considere¬ 
vole e quindi quando accade ce ne accorgiamo. Ho letto di per¬ 
sone con hard disk che hanno dovuto aspettare dei minuti 
perché il validator finisse il suo lavoro e anche i floppy posso¬ 
no richiedere parecchio tempo. La maggior parte di noi, ormai, 
ha imparato ad aspettare che termini anche quell’ultima piccola 
operazione di scrittura, ma a volte diventiamo comunque impa¬ 
zienti e paghiamo caro per la nostra fretta la volta successiva 
che usiamo quel disco. 

Nei due campi successivi troviamo ancora una differenza fra il 
vecchio e il nuovo sistema. Nel vecchio, i campi BitMapKeys e 
BitMapExtension (vedi le relative strutture in fondo all'artico¬ 
lo) sono invertiti e la BitMapKeys viene usata dalla posizione 
24 in avanti. 

Nel FFS, immediatamente dopo i flag di bitmap, troviamo una 
serie di 25 posizioni nelle quali memorizzare i numeri dei set¬ 
tori che contengono le bitmap. Ogni posizione in una bitmap 
può memorizzare l’informazione relativa a 32 settori, così, su 
floppy, un settore bastava sempre e tutte le altre posizioni era¬ 
no vuote. Con gli hard disk il bisogno aumenta e il problema 
viene risolto grazie all’estensione dei bitmap. 

Se l’ultima posizione nella tabella dei bitmap contiene un valo¬ 
re diverso da zero, il sistema capisce che ci sono altri blocchi 
bitmap elencati e quindi consulta il blocco BitMapExtended 
per trovarli. Quest’ultimo è uno solt da 32 bit contenente il nu¬ 
mero del blocco che contiene i dati in eccesso. 


# g 880 

Block 880 read (cyl 40, sur 0, sec 0) 

# t 75 83 

75: 0 ; FFS Workbench 

76: 0 

77: 0 

78: -1 ; il bitmap è valido 

79: 881 ; bitmap nel settore 881 

80: 0 
81: 0 
82: 0 
83: 0 

Una correzione a questa parte del blocco root ha permesso alla 
Commodore di rimuovere il limite di 53 Megabyte sulle di¬ 
mensioni delle partizioni che affliggeva il vecchio file System. 

Il vecchio sistema assumeva che il blocco root avesse i bit di 
protezione, come gli altri blocchi contenenti una directory, 
quindi procedeva a scrivere questi bit nel campo che puntava al 
blocco di estensione del bitmap. Questo succedeva perché i bit 
di protezione nelle directory d’utente occupano la stessa posi¬ 
zione usata per il numero del blocco di estensione nella direc¬ 
tory root. Nel FFS questo bug è stato corretto, ma gli utenti del 
vecchio sistema continueranno ad avere questa limitazione di 
53 Megabyte. 

La parte rimanente della directory root è la stessa in entrambi i 
sistemi: la data dell'ultima modifica del blocco root, il nome 
del disco, la data deH’ultima modifica di un file o di una parti¬ 
zione (anche se quest’ultima parte non funziona ancora a dove¬ 
re), la data di creazione del disco, alcuni slot riservati per usi 
futuri e infine una long word che identifica il tipo di blocco 
(numero secondario). 


Un blocco BitMapExtension non ha neppure il checksum per 
non occupare inutilmente spazio vitale. Contiene infatti 127 in¬ 
dirizzi di blocchi e il numero del prossimo blocco di estensio¬ 
ne. Dal momento che tutte queste liste vengono lette dal fondo 
alla cima, il primo numero in questo settore è quello che punta 
al prossimo blocco di estensione. 

Ecco degli estratti ottenuti da dischi OFS (vecchio) e FFS 
(nuovo). I dischi non sono identici, quindi alcune differenze 
nei numeri sono inevitabili e trascurabili. 

# sd 

2 

# t 75 83 

75: 0 

76: 1357 

77: 0 

78: -1 

79: 1029 

80: 0 
81: 0 
82: 0 
83: 0 


Nel FFS c’è ancora un errore nel Kickstart 1.3 che causa la 
scrittura della data dell’ultima modifica al blocco root anche 
nello slot riservato alla data dell'ultima modifica a un file o a 
una partizione. 

I veri blocchi di bitmap, a differenza dei blocchi di estensione, 
hanno un checksum. Ricordate che i blocchi di estensione, in¬ 
vece, contengono solo altri numeri di settore. 

I blocchi di bitmap indicano quali settori del disco sono usati e 
quali sono liberi. Un blocco bitmap ha il primo slot occupato 
da un checksum, seguito da 127 long word, ognuna rappresen¬ 
tante 32 settori, che fa 4064 settori per blocco. Questo numero 
non arriva a coprire 2 Mbyte, nel caso vogliate calcolare il nu¬ 
mero di blocchi di bitmap necessari al vostro disco o alla vo¬ 
stra partizione. Se un bit di queste 127 long word è settato a 
uno, il blocco al quale corrisponde è disponibile all’uso. Quan¬ 
do questi è già in uso, invece, il bit viene messo a zero. 

A prima vista questo metodo può sembrare rincontrano di 
quanto converrebbe fare normalmente. Riflettendo, possiamo 
vedere che l’avere usato uno zero per indicare un blocco libero 
avrebbe richiesto una esame individuale di ogni bit, ma il test 
per verificare che una long word non sia a zero permette di 


; OFS Workbench 

; il bitmap è valido 
: bitmap nel settore 1029 


imi 



















■ r 

controllare 32 bit alla volta. Se si rileva un numero diverso da 
zero, allora quella long word può essere esplorata per vedere 
quali blocchi siano disponibili. Questo metodo risulta più velo¬ 
ce di quello di controllare ogni long word per trovare un bit a 
zero. 

Una veloce occhiata a uno qualsiasi degli altri blocchi non mo¬ 
strerebbe alcuna differenza, anche se ce ne sono alcune, che 
abbiamo visto sopra. Anche un file header non mostra alcuna 
differenza di rilievo. Secondo un messaggio apparso su Usenet, 
il numero di blocchi del file (terza posizione nel blocco header) 
non viene aggiornato dal fast filing System, ma rimane tuttavia 

Per quanto ne so, non ci sono stati cambiamenti nella struttura 
di una directory utente sotto fast file System. I primi 78 slot 
sembrano essere gli stessi contenuti in una directory root. 

presente nella sua posizione. 

Il prossimo elemento nella catena per arrivare a un file è il 
blocco file header, l’intestazione di un file, che serve a vari 

Le directory d’utente non necessitano di informazioni relative 
al bitmap, quindi queste sono sostituite da posizioni inutilizzate 
(sette, ma non contigue), dai bit di protezione e da un campo di 
commento, 80 caratteri del quale sono a disposizione dell’uten¬ 
te. C’è solo un campo contenente la data in una directory uten¬ 
te, occupato dalla data di creazione della directory stessa. 

scopi. Innanzitutto, questo tipo di blocchi viene utilizzato nelle 
strutture FileLock. La Commodore ci ha detto che le strutture 
FileLock continueranno a essere supportate in futuro. 

Quando un file viene bloccato (locked), il campo /7_key di Fi¬ 
leLock conterrà il numero del blocco header del file. Questo 
blocco individua l’inizio del file in un disco o in una partizio- 

Il campo riservato al nome della directory d’utente mette a di¬ 
sposizione 36 caratteri, anziché 40, ma questo è più che suffi¬ 
ciente, dal momento che il nome, in entrambi i casi, è limitato 
a 30. Una directory utente può essere parte di una catena, quin¬ 
di c’è una posizione riservata al numero del prossimo blocco 
della catena, una per il numero di blocco della directory prece¬ 
dente e una per il numero secondario del tipo di file. 

ne, o, nel caso di un RAM disk, l’indirizzo al quale il file è at¬ 
tualmente memorizzato. 

Il blocco header contiene le informazioni riguardanti il file a 
cui appartiene: il suo nome, quando è stato creato, i suoi bit di 
protezione e i puntatori ai blocchi che contengono i dati e a 
quelli di estensione. 

Il concatenamento degli hash è interessante. Prima di passare 
ad Amiga usavo un computer Commodore molto più semplice, 
il quale aveva una singola directory (nel caso dell’8050 due di¬ 
rectory). Queste erano locate, come nel caso della nostra root, 
al centro del disco e ognuna conteneva le informazioni di tutti i 
file presenti sul disco. Era molto facile leggere le directory as¬ 
sai velocemente, ma era altrettanto facile esaurire lo spazio di¬ 
sponibile per aggiungere nuovi file. Ogni directory poteva 
contenere un numero finito di file e, una volta raggiunto questo 
numero, il disco risultava pieno, senza badare a quanto spazio 
rimanesse effettivamente libero sul supporto magnetico. 

I blocchi file header usano le prime sei posizioni per informa¬ 
zioni di sistema come il tipo di blocco, il numero del blocco, il 
numero di blocchi nel file, il numero del primo blocco dati e il 
checksum. 

Queste informazioni sono seguite da una tabella con 72 posi¬ 
zioni, ognuna delle quali contiene il numero di un blocco dati 
usato in questo file. Gli slot vengono riempiti a partire dal nu¬ 
mero 78 per finire al numero 6. Se il file dovesse richiedere più 
di settantadue settori, il numero del blocco di estensione verrà 
posizionato nello slot 126. 

Nell’Amiga il concatenamento dei valori di hash ha risolto 
questo problema. Se due nomi di file ottengono lo stesso nu¬ 
mero di hash dall’apposita routine, il primo viene messo nella 
directory root e il secondo viene raggiunto tramite la posizione 
riservata alla catena hash che si trova nell’header del primo fi¬ 
le. 

Dopo la tabella si trovano le solite posizioni riservate per usi 
futuri (tre in questo caso) e quelle necessarie a immagazzinare 
la data e il nome del file. Segue lo slot della catena hash. il nu¬ 
mero della directory genitore, il numero del blocco di estensio¬ 
ne e il numero secondario del tipo di file (-3 in questo caso). 

Pertanto, se il mio primo file è stato messo nello slot numero 
nove della directory root, quando salvo un file diverso con un 
hash uguale a nove, il sistema si sposta alla posizione nove del¬ 
la root, legge il settore lì indicato e paragona il nome di quel fi¬ 
le con quello che ho indicato. Se questi sono differenti, viene 
letto il contenuto dello slot della catena hash e viene caricato il 
settore eventualmente indicato. Il processo si ripete fino a 
quando non si trova il file desiderato. L'ultimo file della catena 
ha uno zero in questa posizione, così il file System sa quando 
interrompere la ricerca. 

Quando arriviamo ai veri blocchi dati, comunque, troviamo un 
cambiamento veramente molto grosso. Le prime sei long word 
nel vecchio sistema contenevano informazioni di sistema mol¬ 
to simili a quelle che si trovano nelle directory. Questo lasciava 
spazio per soli 488 byte di dati, dal momento che gli altri 24 
erano utilizzati in questa maniera. Il fatto non occupava solo 
uno spazio maggiore del disco, ma rallentava anche il file Sy¬ 
stem. 

Proviamo a cercare un file, utilizzando DiskED, in entrambi i 
file System e quindi facciamo un paragone. Il valore hash di c è 

14; quello di run è 6. Cominciamo quindi dal principio: travia- 

Allora cosa c’è veramente di nuovo? 

mo la directory c e rintracciamo il comando run nei due modi: 

I cambiamenti nei blocchi boot, directory e bitmap sono picco¬ 
li. È quando arriviamo ai blocchi data che i cambiamenti nel 
FFS diventano veramente visibili. 

Per trovare la directory c, prima leggiamo il blocco root: 

FastFileSystem OldFileSystem 

C 

L 5lJ 1 ti 
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0 

0 

72 


/hash table 


-1199734386 


0: 

1 

2 

3 

4 

5 

6 

7 

8 
9 


0 

0 

72 


;tipo di 
.•blocco (corto) 


/ dimensioni 


1: 883 

2 : 6 

3: 0 

4: 884 


9069645323 ;checksum 
0 

882 

0 

0 


-55752819 

0 

0 


1: 888 ; numero di 

.•questo blocco 

2: 6 /settori usati in 

.•questo file 

3: 0 ; data block per 

.•questo file 

4: 889 /primo blocco 

/del file 
5: -55752929 

6 : 0 

6: 0 


10: 

0 

10 

884 

71: 

0 

71: 

0 


11: 

0 

11 

0 

72 : 

906 

72: 

873 

/ultimo blocco 

12: 

0 

12 

0 





/usato da 'run' 

13: 

0 

13 

885 

73: 

905 

73: 

872 


14: 

882 

14 

887 /blocco 

74 : 

904 

74 : 

871 





/contenente la 

75: 

903 

75: 

870 





/directory C 

76: 

902 

76: 

879 

/secondo blocco 









/usato da 'run' 

Successivamente, leggiamo 

il settore che contiene la directory 

77: 

884 

77: 

889 

/primo blocco 

C ed esaminiamo l'elemento nello slot 6, che è il valore hash di 





/usato da 'run' 

run. 




78: 

0 

78: 

0 


FastFileSystem 


OldFileSystem 

E. quando leggiamo 

il blocco 884 del 

FFS, oppure il blocco 





887 del OFS, osserviamo infine 

la maggiore differenza tra i 


# g 882 # g 887 /leggiamo il 

/blocco dove 
/si trova C 

Block 882 read Block 887 read 

(cyl 40, sur 0, sec 2) (cyl 40, sur 0, sec 7) 


due sistemi. Qui, ho cambiato dalla notazione decimale a quel¬ 
la esadecimale, per mostrare con maggior chiarezza che cosa 
succede esattamente. 


FastFileSy sterri 


OldFileSystem 


# 

t 0 10 

# 

t 0 10 

/stampa le 




# t 0 20 






/prime 10 


0: 

00000008 

; tipo di 






/posizioni 





/blocco (data) 

0 

2 

0 

2 

/tipo di blocco 


1 : 

00000378 

/numero di 






/(corto) 





/questo settore 

ì 

882 

1 

887 

/numero di 


2 : 

00000001 

/posizione 






/questo blocco 





/nel file 

2 

0 

2 

0 



3: 

000001E8 

/ammontare dei 


3 

0 

3 

0 






/dati (488 byte) 

4 

0 

4 

0 



4 : 

0000036F 

/prossimo blocco 


5 

-23315566 

5 

-23327944 / checksum 





/nel file (879) 

6 

883 

6 

888 

/blocco header 


5: 

7CDCFCB7 

/Checksum 






/di 'run' 

0: 

000003F3 

6: 000003F3 

/hunk header, 

7 

885 

7 

890 






/inizio del file 

8 

889 

8 

897 


1 : 

ooooooóo 

7: 00000000 


9 

891 

9 

899 


2 : 

00000002 

8: 00000002 



10: 895 


10 : 


901 


I blocchi header sono gli stessi per i due file System. È necessa¬ 
rio visitare questo blocco, comunque, per trovare i numeri dei 
settori che contengono i dati reali di 'run'. Adesso ci spostiamo 
al blocco 883 sul FFS e al blocco 888 sul OFS. i quali conten¬ 
gono il blocco file header di run: 


00000000 

00000001 

0000004F 

00000226 

000003E9 

0000004F 

286A0164 


10: 700C4E95 


9 

10 

11 

12 

13 

14 

15 

16 


00000000 

00000001 

0000004F 

00000226 

000003E9 /hunk_code 

0000004F 

286A0164 

700C4E95 


FastFileSystem 
0: 000003F3 

0: 2 


OldFileSystem 

6: 000003F3 zhunk header, 

0: 2 /Tipo di blocco 

/(short) 


Come potete vedere, i dati sono identici, ma il vecchio file Sy¬ 
stem ha 24 byte di informazione che non viene utilizzata nel 
fast system. 
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progettare con 


L’ELETTRONICA 

Subito tutta l’elettronica nelle tue mani. 

Se ami l’elettronica e il fai da te, se progettare, costruire e conoscere ti diverte e ti 
appassiona, il Gruppo Editoriale Jackson ti propone PROGETTARE CON L’ELETTRO¬ 
NICA, 20 preziose guide ricche di progetti pratici, idee e suggerimenti. 

Argomenti approfonditi, circuiti collaudati e di facile realizzazione, fotografie e sche¬ 
mi, ti permetteranno di approfondire le tue conoscenze e arricchire la tua esperienza. 

costruire per conoscere 


progettare con 


L’ ELETTRONICA 


LUCI PSICHEDELICHE 


LUCI PSICHEDELICHE 

I più spettacolari sistemi di illuminazio¬ 
ne, dalla festicciola tra amici alla gran¬ 
de discoteca, sono illustrati con dovizia 
di particolari e di soluzioni per ogni 
esigenza. Inoltre, il progetto completo 
di una centralina psichedelica di facile 
realizzazione. 


UEL^RONICA 


AMPLIFICATORI 
A CIRCUITI INTEGRATI 



JACKSON 



progettare con 


progettare con 


AMPLIFICATORI 
A CIRCUITI INTEGRATI 

Scopri, passo dopo passo, quali carat¬ 
teristiche deve possedere un buon am¬ 
plificatore ad alta fedeltà e come, gra¬ 
zie alla tecnologia attuale, sia possibile 
realizzarne uno di ottima qualità. 


GENERATORI 
DI FUNZIONE 


L’ ELETTRONICA 


GENERATORI DI FUNZIONE 



È possibile sintetizzare, nel proprio la¬ 
boratorio elettronico, segnali dalle for¬ 
me d'onda più strane e dalle frequenze 
più disparate? Questo libro spiega co¬ 
me realizzare da soli, con minima spe¬ 
sa, uno strumento indispensabile per 
l’audiofilo avanzato e utilissimo a tutti 
gli sperimentatori elettronici. 


MUSICA ELETTRONICA 

Un primo approccio col magico e com¬ 
plesso mondo dei sintetizzatori, delle 
tastiere elettroniche, dell’informatica 
musicale. Viene descritto il progetto di 
un preamplificatore per chitarra elettri¬ 
ca in grado di ottenere diversi effetti 
speciali. 



GRUPPO EDITORIALE 

JACKSON 


L ELETTRONICA 


MUSICA ELETTRONICA 
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Questo velocizza le cose in molti modi. Ovviamente ci sono 
più dati in ogni settore, quindi si effettuano meno operazioni di 
lettura. Meno ovviamente, bisogna compiere alcune azioni per 
rendere i dati pronti all’uso. 

Sotto OFS la traccia viene letta nell'apposito buffer e decodifi¬ 
cata, quindi i primi 24 byte all’inizio di ogni settore sono ri¬ 
mossi prima che l’informazione venga copiata nel buffer 
dell’utente. Con il nuovo sistema tutta l’operazione può essere 
omessa e i dati vengono trasferiti tramite DMA nel buffer del¬ 
l’utente. Questo risparmio, moltiplicato per ogni settore, può 
risultare in grosse differenze nella quantità di tempo richiesto 
per portare a termine l’intera operazione. 

Per ottenere questo risparmio di spazio e di tempo sono stati 
però sacrificati alcuni mezzi per il recupero di file danneggiati. 
A prima vista può sembrare che nel FFS non ci sia alcun mez¬ 
zo per poter recuperare alcunché, ma questo non è compieta- 
mente vero. 

In aggiunta ai blocchi che vediamo, esistono zone di intestazio¬ 
ne (label area) per ciascuno di questi settori. Non ho trovato 
documentazione per queste zone sotto FFS, ma sotto il vecchio 
sistema, il RKM (Rom Kernel Manual) ci diceva che il loro 
contenuto è: 

2 byte a 00 

2 byte a Al (byte di sincronismo MFM) 

1 byte per indicare il tipo di formato 
1 byte per il numero della traccia 
1 byte per il numero del settore 
16 byte non utilizzati sotto OFS 

(credo che non vengano utilizzati neanche sotto 
FFS),presenti per usi futuri per il recupero 
degli errori 

4 byte per il checksum di questa zona 
4 byte per il checksum del blocco dati 


Le informazioni relative alla traccia, al settore e al checksum 
sono ancora disponibili, qui nella label del settore che non ve¬ 
diamo nei nostri disk editor. Era ridondante ripetere queste in¬ 
formazioni nelle prime sei posizioni del settore, anche se si è 
rivelato utile per recuperare dischi e per salvaguardare l’inte¬ 
grità dei file. 

I blocchi dati non hanno più il puntatore al loro header genitore 
e adesso dipendiamo interamente dai questi ultimi per recupe¬ 
rare i dati. 

Cosa riserva il futuro? 

Le versioni future del sistema operativo porteranno cambia¬ 
menti assai più signiicativi di quelli arrivati con 1 ’ 1.3. Uno stu¬ 
dio sull’organizzazione del sistema ci ha detto fin dal principio 
che non avremmo sempre avuto blocchi da 512 byte l’uno ed è 
abbastanza probabile che cominceremo ad avere blocchi di di¬ 
mensioni variabili già con la versione 1.4. 

Le maggiori dimensioni dei blocchi comporteranno una dimi¬ 
nuzione delle operazioni di lettura e delle operazioni di sposta¬ 
mento delle testine, rendendo più veloce il sistema. Le tabelle 
hash saranno finalmente più lunghe di 72 slot, favorendo una 
riduzione del numero di collisioni dei valori di hash e riducen¬ 
do il ricorso al loro concatenamento. Le fondamenta per en¬ 
trambe queste migliorie sono già presenti, quindi possono 
essere implementate con inconvenienti ridotti al minimo. Pro¬ 
babilmente seguiranno altri cambiamenti. 

II software che accede al disco, seguendo le procedure racco¬ 
mandate ufficialmente, continuerà a funzionare (obbedisci alle 
regole e tu e il tuo software soppravviverete). 

Colui che utilizzerà metodi scorretti per guadagnare un tempo¬ 
raneo vantaggio in velocità, soccomberà quando il sistema ver¬ 
rà cambiato. 


Strutture C per i diversi blocchi del disco (basati su quelle pubblicate in AmigaMail 

Novembre/Dicembre 1988): 


Blocco root 




struct 

RootBlock { 



LONG 

Type; 

/* 

corto (2) */ 

ULONG 

OwnKey; 

/* 

non utilizzato, 0 */ 

ULONG 

SeqNum; 

/* 

non utilizzato */ 

ULONG 

HtSize; 

/* 

numero di slot nella hash table */ 

ULONG 

Nothingl; 

/* 

uso riservato, messo a zero */ 

LONG 

Checksum; 



ULONG 

HashTable[72] ; 

/* 

hash table con 72 slot */ 

LONG 

BitmapFlags; 

/* 

-1 se valida; 0 se non validata */ 

ULONG 

BitmapKeys [25]; 

/* 

per FFS; OFS ha qui BitmapExtended */ 
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ULONG 

BitmapExtend; 

/* 

dov'è la prossima lista di BitmapKeys? */ 




/* 

Solo nel FFS. L'OFS aveva un problema con 

*/ 



/* 

questo slot, come spiegato nell'articolo 

*/ 

ULONG 

DirAltered[3]; 

/* 

data dell'ultima modifica effettuata /* 


char 

Name[40]; 

/* 

stringa BCPL, nome del disco */ 


ULONG 

DiskAltered[3] ; 

/* 

attualmente c'è un bug nel FFS, dovrebbe 

*/ 



/* 

mostrare la data dell'ultima alterazione 

*/ 



/* 

di un file su questo disco */ 


ULONG 

DiskMade[3]; 

/* 

data di formattazione del disco */ 


ULONG 

Nothing2; 

/* 

uso riservato */ 


ULONG 

Nothing3; 

/* 

uso riservato */ 


ULONG 

Nothing4; 

/* 

uso riservato */ 


LONG 

SecondaryType; 

/* 

tipo 1, ROOT */ 



} 


Directory 


struct 

UserDirectoryBlock 

{ 


LONG 

Type; 

/* 

corto (2) */ 

ULONG 

OwnKey; 

/* 

numero di questo settore */ 

ULONG 

Sparel; 

/* 

tutti i campi 'spare' sono messi a zero */ 

ULONG 

Spare2; 

/* 

e riservati per un uso futuro */ 

ULONG 

Spare3; 



LONG 

Checksum; 



ULONG 

HashTable[72]; 

/* 

numero di slot disponibili in questa tabella */ 

LONG 

Spare4; 



LONG 

Spare5; 



ULONG 

Protection; 

/* 

bit di protezione per questa directory */ 

LONG 

Spare6; 



char 

Comment[92]; 

/* 

solo 80 disponibili all'utente */ 

ULONG 

Created[3]; 

/* 

data di creazione o modifica della directory */ 

char 

DirName[36]; 

/* 

nome della directory, solo 30 byte usati */ 

LONG 

Spare7 [ 7 ] ; 



ULONG 

HashChain; 

/* 

dov'è il prossimo file con lo stesso valore */ 



/* 

di hash? (0 se non ce ne sono più) */ 

ULONG 

Parent; 

/* 

blocco della directory genitore */ 

ULONG 

Spare8; 



LONG 

SecondaryType; 

/* 

tipo 2, ST_USERDIR */ 


} 


File header 


struct 

FileHeaderBlock { 




LONG 

Type; 

/* 

corto 

(2) */ 

ULONG 

OwnKey; 

/* 

numero 

di questo settore */ 

ULONG 

HighSeq; 

/* 

quanti 

blocchi sono utilizzati per questo */ 



/* 

file? 

Usato nel OFS, non aggiornato nel FFS 

ULONG 

DataSize; 

/* 

numero 

di blocchi dati in questo file */ 

ULONG 

FirstBlock; 

/* 

da che 

settore comincia questo file? */ 

LONG 

Checksum; 




ULONG 

DataBlocks[72]; 

/* 

elenco 

fino a 72 settori usati in questo */ 



/* 

file. 

cominciando dal #71, andando verso */ 



/* 

il #0. 

Se ne occorrono di più si usa il */ 



/* 

blocco 

di estensione */ 

ULONG 

Sparel; 




ULONG 

Spare2; 
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ULONG 

Protect; 

/* 

bit di protezione per questo file */ 

ULONG 

Date[3]; 

/* 

data di creazione del file */ 

char 

FileName[36]; 

/* 

nome del file, solo 30 sono usati */ 

ULONG 

Spare3[7]; 



ULONG 

HashChain; 

/* 

blocco header del prossimo file che */ 



/* 

ha lo stesso valore hash di questo */ 

ULONG 

Parent; 

/* 

blocco della directory genitore */ 

ULONG 

Extension; 

/* 

puntatore a un altro blocco come questo 



/* 

che contiene un'altra parte della lista 



/* 

dei blocchi dati di questo file */ 

LONG 

Second; 

/* 

tipo -3 */ 


I blocchi dati sotto FFS non hanno alcuna struttura e sono interamente riempiti di dati. Per il OFS la struttura dei blocchi dati è la 
seguente: 


struct FileDataBlock 


LONG 

ULONG 

ULONG 

ULONG 

ULONG 

LONG 

char 

} 


Type; 
OwnKey; 
SeqNumber; 
DataSize; 
NextBlock; 
Checksum; 
Data [4 88] ; 


/* tipo 8, blocco dati */ 

/* numero di questo settore */ 

/* numero di sequenza di questo blocco nel file */ 
/* quanti byte di dati in questo blocco? */ 

/* quale settore ospita prossimo blocco dati? */ 

/* 488 byte di dati */ 


(segue eia pagina 25 ) 


Linguaggio Assembly 


Possiamo adesso chiedere all’assembler di mettersi al lavoro. 
La maniera normale consiste nel digitare <nome dell'assem¬ 
blei TEST. Controllate nella sua documentazione, nel caso 
sia richiesto qualcosa di diverso. 

Se ci vengono segnalati degli errori, torniamo indietro, correg¬ 
giamoli e riproviamo ad assemblare. Alla fine il programma ef¬ 
fettuerà un passaggio senza segnalare problemi e produrrà un 
file oggetto, riconoscibile dal suffisso .o oppure .obj. In altre 
parole, dovremmo avere adesso un file chiamato TEST.O o 
TEST.OBJ. Ma il nostro programma non è ancora pronto per 
essere eseguito. 

Alcuni assembler, come AssemPro e Devpac, saltano la fase di 
link e generano direttamente un eseguibile: se questo è il vo¬ 
stro caso, non avrete bisogno del linker. 


Il comando BLINK TEST.O TO TEST 
oppure BLINK TEST.OBJ TO TEST 

convertirà il nostro programma in forma eseguibile, pronto per 
essere lanciato. Digitiamo TEST e il computer dovrebbe ri¬ 
spondere Hello, World!. 

Avete appena messo assieme il vostro primo semplice pro¬ 
gramma in linguaggio assembly per Amiga. Come vi sentite? 
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Devpac Amiga della HiSoft 

Una recensione della versione 2 di questo famoso pacchetto di 

sviluppo per 68000 


di Danny Ross 

Danny Ross sta frequentando l’ultimo anno di corso di Scienze 
del!' Informazione. // suo tempo libero si divide fra lo sviluppo 
di algoritmi di incanalamento per network di transputer, fra la 
programmazione di Amiga come freelance e fra la scrittura di 
software per il PC. Vivendo in una casetta in stile Gotico nel 
Galles del sud, con altri due maniaci della programmazione, la 
sua idea di rilassamento consiste nell’ esplorare tutte le ultime 
chiamate delle librerie di Amiga! 

Chiunque abbia usato un prodotto della HiSoft si troverà im¬ 
mediatamente a suo agio con Devpac Amiga; tutto è integrato 
in quel familiare ambiente di sviluppo che è diventato una ca¬ 
ratteristica dei linguaggi della HiSoft. 

Con la versione 2 di Devpac, la HiSoft ha nettamente migliora¬ 
to il loro già eccellente sistema di sviluppo per 68000, renden¬ 
dolo indispensabile per il programmatore serio. 

GenAm2 - l'editor/coordinatore 

Devpac Amiga è scomposto in tre programmi principali, Ge- 
nAm2, Genlm2 e MonAm2. Digitando GenAml nel CLI (non 
esiste, stranamente, alcun supporto per il Workbench) invoche¬ 
remo la finestra dell'editor GenAm2 contenente una breve li¬ 
nea di stato, in fondo, che riporta la posizione del cursore e la 
memoria disponibile. 

L'editor è configurato inizialmente con un buffer per il testo di 
60000 byte, che può essere aumentato o diminuito per mezzo 
di una opzione nel menu Preferences. Svariate altre caratteristi¬ 
che, come la dimensione dei tab, V autoindentazione e il ritorno 
automatico, sono ora disponibili in questo menu e possono es¬ 
sere modificati con il mouse direttamente all'interno dell'edi- 
tor (le versioni precedenti richiedevano un programma 
separato, Genlns). 

I comandi dell’editor non sono cambiati molto e le orribili e 
antiquate combinazioni di tasti usate dal Wordstar sono tuttora 
supportate. Fortunatamente, adesso le operazioni di selezione, 
taglio e inserimento di blocchi mettono in evidenza il testo su 
cui si svolge l'operazione, pur utilizzando ancora i tasti di fun¬ 


zione. Personalmente avrei preferito lo standard utilizzato nei 
programmi TxED/CygnusED. 

Una volta inserito il nostro codice sorgente, GenAm2 comincia 
veramente a trovare il suo ritmo. Selezionando Assemble dal 
menu Program (o premendo Amiga-A) verrà visualizzato una 
finestra di opzioni estremamente utile (novità nel 2.0). Alcune 
di queste opzioni sono semplicemente dei sostituti per le diret¬ 
tive vecchio-stile dell'assembler (OPT L+ e il resto, che sono 
ancora disponibili), ma altre sono completamente nuove. Ades¬ 
so è possibile dire a GenAm2 di mettere il codice prodotto nel 
disco o nella memoria. 

(ìenlm2 - Passembler 

Quando sono state effettuate tutte le selezioni del caso, si sele¬ 
ziona il gadget Assemble nella finestra delle opzioni di Ge- 
nAm2, che, oltre a essere un editor, funge anche da 
coordinatore per gli altri due programmi del pacchetto. Viene 
quindi caricato Passembler vero e proprio, chiamato Genlm2, 
che procede alla elaborazione del codice sorgente. Dopo essere 
stato chiamato per la prima volta, Genlm2 rimane in memoria, 
pronto a essere riutilizzato per la prossima volta, eliminando 
così i tempi morti di caricamento. 

Con il codice appena prodotto in memoria, il debugger Mo- 
nAm2 può essere invocato da GenAm2, permettendo di ottene¬ 
re un ciclo di edit-assemble-debug molto rapido. Altre opzioni 
che entrano in gioco durante Passemblamento di un file com¬ 
prendono una direttiva ’Fast’, che velocizza l'assemblaggio 
trattenendo i file include in memoria (richiede abbastanza 
RAM libera), uno switch per ottenere codice eseguibile o lin¬ 
kabile e la possibilità di specificare la destinazione del file .lst 
(listato). 

Queste e altre opzioni possono essere selezionate nell’apposita 
finestra di opzioni di GenAm2, oppure possono essere specifi¬ 
cate sulla linea di comando quando si lancia Genlm2 da CLI. 
L’assembler può essere, infatti, utilizzato sia nell'ambiente in¬ 
tegrato GenAm2-GenIm2-MonAm2, sia come programma a sé 
stante, come i più classici assembler disponibili sul mercato. In 
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questo modo, chi preferisce, può continuare a usare il suo edi¬ 
tor preferito per lavorare sul sorgente, quindi lanciare Genlm2 
per assemblare e poi utilizzare MonAm2 o un altro debugger di 
propria scelta. 

Adesso è supportata l'intera serie di macro caratteristiche degli 
assembler Amiga, quindi Genlm2 può rimpiazzare prodotti co¬ 
me quello della Metacomco senza problemi. 

MonAm2 - il debugger simbolico 

La terza parte di Devpac è costituita dal programma MonAm2. 
Questo è il versatile debugger simbolico della HiSoft che può 
lavorare come programma di utilità a sé stante oppure in cop¬ 
pia con GenAm2. Quando GenAm2 è attivo, MonAm2 è di¬ 
sponibile dal menu Program per lavorare sia sul codice 
prodotto da MonIm2 in memoria, sia su qualsiasi file eseguibi¬ 
le AmigaDOS. 

La prima cosa che si nota di MonAm2 è che lavora su un pro¬ 
prio schermo. Questa è un'idea eccellente perché significa che 
il programma sotto esame può aprire i propri screen e definire 
qualsiasi tipo di display, senza influenzare le sessioni di debug¬ 
ging di MonAm2 (assumendo che il programma in questione 
usi delle chiamate legali). 

Naturalmente, se apriamo uno schermo senza barra di sposta¬ 
mento (drag bar) o senza gadget di profondità, allora potrem¬ 
mo accorgerci di avere perso lo schermo di MonAm2, 
nonostante ci sia una funzione incorporata in MonAm2 che 
manda lo schermo sullo sfondo. Magari la HiSoft potrebbe for¬ 
nire un programma di utility che permetta di passare da uno 
schermo all'altro mediante l’uso di una hot-key. Utility di que¬ 
sto genere si possono comunque trovare nel vasto oceano di 
software di pubblico dominio. 

Come menzionato in precedenza, MonAm2 è un debugger 
simbolico. Operando le appropriate selezioni all'interno di Ge- 
nAm2, questi produrrà un file di output che contiene informa¬ 
zioni sui simboli presenti nel programma. Caricando questo 
programma con MonAm2, tutte le etichette che abbiamo usato 
nel nostro sorgente verranno visualizzate nel codice disassem¬ 
blato, cosa che può rendere l’operazione di debugging più faci¬ 
le di svariati ordini di grandezza. 

MonAm2 è composto di 3 finestre, con una quarta opzionale 
che può essere usata per visualizzare un file di testo (normal¬ 
mente il nostro codice sorgente). Ogni finestra mostra informa¬ 
zioni utili riguardanti il programma in esecuzione. La più 
grande delle tre contiene la stampa di tutti i registri del 68000 
(inclusi SR, SSP e il PC). 

La seconda in ordine di grandezza è la finestra Disassembly, 
che normalmente visualizza il codice negli immediati paraggi 
del Program Counter. Parte di questa finestra deve essere sacri¬ 
ficata se si utilizza la possibilità di vedere il file sorgente nella 
sua finestra separata. La terza finestra è una finestra diretta sul¬ 
la memoria. 

Ci sono, in effetti, altre due finestre che rimangono quasi sem¬ 


pre nascoste alla vista. Una contiene delle informazioni di 
help, che in realtà non danno un grande aiuto, ma perlomeno 
fornisce informazioni dettagliatissime sulla sitazione attuale 
dell'occupazione di memoria. L'altra è una finestra che tiene 
una traccia delle ultime istruzioni eseguite e dello stato dei re¬ 
gistri durante la loro esecuzione. Quest’ultima finestra è molto 
preziosa e fa di MonAm2 un prodotto molto più utilizzabile. 

Tutti i comandi di MonAm2 sono impartiti da tastiera. Sebbene 
questo consenta la massima rapidità d’uso, è molto scomodo 
dover ricordare le varie combinazioni di tasti normali oppure 
associati a CTRL o ad AMIGA (non che alcuni di questi non 
siano perfettamente azzeccati, come la combinazione che atti¬ 
va Trace Cali e Set Breakpoint After Current Instruction. 

Naturalmente, il mancato utilizzo dell’interfaccia grafica per¬ 
mette a MonAm2 di rimanere contenuto come dimensioni e 
l'ultima cosa che vorremmo, durante il debugging di un grosso 
programma, sarebbe di avere un debugger di 200K piazzato in 
sottofondo. Nonostante questa considerazione, MonAm2 po¬ 
trebbe fare certamente un uso migliore di Intuition, perlomeno 
con un box per la selezione dei file! 

Conclusione 

L’intero processo di edit-assemble-debug è stato velocizzato in 
maniera significativa, facendo di GenAm2 un prodotto straor¬ 
dinariamente brillante. In paragone, AssemPro è una schifezza. 

Pur formando, sotto il controllo dell'editor GenAm2, un am¬ 
biente perfettamente integrato, T assembler Genlm2 e il debug¬ 
ger MonAm2 possono essere utilizzati in maniera 
completamente indipendente, adattandosi a qualsiasi ambiente 
di lavoro già utilizzato dal programmatore. 

Il pacchetto Devpac della HiSoft, pur beneficiando di dimen¬ 
sioni contenute, è molto potente per lo sviluppo sul micropro¬ 
cessore 68000. Ci sarebbero moltissime opzioni e funzioni che 
potrebbero essere aggiunte, ma al costo di un aumento delle di¬ 
mensioni che risulterebbe inaccettabile per la maggior parte 
degli sviluppatori (MonAm2 è lungo 25788 byte, Genlm2 
29004 byte e GenAm2 appena 23744 byte). 

Sebbene la HiSoft dica che Devpac è adatto per l'intera fami¬ 
glia 680x0 (implicando, quindi, il supporto perlomeno del 
68010), entrambi GenAm2 e MonAm2 non sono stati in grado 
di compilare o disassemblare correttamente il mio codice per 
68010. La migliore performance è venuta da GenAm2 che mi 
ha detto che MOVE CCR.D0 era un’istruzione per 68010 e che 
l'aveva sostituita con MOVE SR.D0. 

Con un prezzo molto ragionevole di 59.95 sterline inglesi (o 
meno), gli utenti di precedenti versioni di Devpac dovrebbero 
certamente pensare a passare alla nuova versione e chiunque 
desideri un ambiente di sviluppo integrato e veloce su 68000 
dovrebbe prendere in seria considerazione l’acquisto di questo 
prodotto. 

HiSoft, The Old School. Greenfield. Bedford. MK45 5DE, In¬ 
ghilterra. Tel: 0044-525-718181 
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Lattice C 5.0 


Uri analisi del nuovo sistema di sviluppo Lattice C 


di Peter Booth 

E disponibile ormai da un po’ di tempo la versione 5.0 del 
compilatore C della Lattice e ci sembra che sia dunque oppor¬ 
tuno descrivere le caratteristiche di questo nuovo prodotto. 
Questa versione si distingue dalle precedenti per il migliora¬ 
mento della adesione allo standard ANSI e per un certo nume¬ 
ro di miglioramenti e aggiunte. 

I manuali 

II sistema di sviluppo offerto dalla Lattice comprende cinque 
dischi e due manuali in formato A5 di buona fattura. La User 
Guide fornisce un’introduzione ragionevolmente graduale per i 
nuovi utenti, precisa le differenze tra il Lattice C e quello defi¬ 
nito nel K & R e presenta le caratteristiche generali dell'am¬ 
biente di programmazione C su Amiga. Il resto del materiale è 
sostanzialmente costituito da manuali di riferimento relativi ai 
vari moduli, comandi e programmi di utilità. 

La sezione che tratta le routine di libreria, il cui numero è co¬ 
stantemente in aumento, è stata molto curata, soprattutto per 
quanto riguarda la presentazione e gli indici. 

Molta dell’informazione presente nei manuali viene fornita al¬ 
lo scopo di dare una descrizione il più esauriente e completa 
possibile per cui può capitare, come, del resto, spesso accade 
per quei pacchetti software che sono rivolti al mercato profes¬ 
sionale, che ì nuovi utenti e i principianti trovino i manuali di 
ardua lettura e comprensione. Fortunatamente nel manuale e 
sui dischetti sono riportati alcuni semplici esempi che possono 
aiutare il principiante nell’uso del compilatore. 

Due compilatori e... 

Nel package possiamo trovare due versioni del compilatore, il 
linker Blink, il Lattice Screen Editor, un ottimizzatore globale, 
un macro assembler, un profiler, una utility per l'analisi post- 
mortem dell’esecuzione di un programma, codice di supporto 
per i programmi del tipo load-and-stay-resident, un compresso¬ 
re di file ... e potremmo andare avanti ancora per molto. 

Viene anche fornito l’intero insieme delle utility chiamato 
Compiler Companion, prima venduto separatamente, e il de- 
bugger a livello sorgente CodeProbe costituisce ora parte inte¬ 
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grante del pacchetto di sviluppo. 

La libreria delle funzioni è cresciuta e ora conta almeno 300 
routine. Una gran parte delle funzioni della library è stata ri¬ 
compilata con i nuovi tool e questo, in aggiunta all’uso di algo¬ 
ritmi migliorati e dell’assembler, ha comportato un ulteriore 
aumento delle prestazioni del codice ottenuto con questa nuova 
versione. 

Come è logico aspettarsi, la versione 5.0 risulta completamente 
compatibile verso l'alto con la versione 4.0. Moduli oggetto e 
librerie possono essere liberamente mischiati, indipendente¬ 
mente dal fatto che siano stati creati con Luna o l’altra versio¬ 
ne; naturalmente, però, solo il codice compilato con la versione 
più recente può sfruttare appieno le potenzialità del nuovo 
compilatore, come il debugging a livello di sorgente. 

Il compilatore e le librerie possono poi ottimizzare la genera¬ 
zione di codice, tenendo conto della eventuale presenza di un 
68010, di un 68020 o di un 68030, come dei coprocessori 
68881 e 68882. 

Il compilatore, inoltre, ha ora un preprocessore che si conforma 
strettamente alle specifiche ANSI; viene riconosciuta anche la 
direttiva defined() e, in aggiunta, i simboli _DATE_ e _TIME_ 
forniscono la data e l’ora della compilazione. La Lattice ha dei 
propri rappresentanti nel comitato ANSI e quindi è in una ec¬ 
cellente posizione per tenersi aggiornata sulle eventuali nuove 
proposte. Questo fatto può far capire perché la Lattice abbia 
profuso un certo impegno per mantenere il proprio compilatore 
conforme allo standard ANSI e abbia previsto un notevole nu¬ 
mero di diagnostici per individuare programmi non conformi 
allo standard. 

Nel package sono presenti due differenti versioni del compila¬ 
tore. La versione completa, che risulta solo 20K più grande, ha 
in più rispetto alla minore solo alcune possibilità relative all’e¬ 
laborazione del listato: è possibile, infatti, ottenere la visione 
dell'espansione delle macro, del conteggio del livello di inne¬ 
stamento dei cicli e del contenuto dei file include. Inoltre, con¬ 
sente la generazione di file prototipo per tutte le funzioni che si 
trovano in un modulo. Quest’ultima possibilità elimina il com¬ 
pito potenzialmente noiosissimo della costruzione di una lista 
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dei prototipi di tutte le funzioni presenti in un progetto. 

In entrambe le versioni, la gestione degli errori è stata sostan¬ 
zialmente migliorata e, tra le altre cose, è ora possibile control¬ 
lare il comportamento del compilatore in risposta a svariate 
condizioni di errore. 

Per quanto riguarda le librerie, oltre ad amiga.lib e alle consue¬ 
te librerie C Lattice, l'insieme (in continua crescita) delle varie 
librerie comprende anche un certo numero di librerie matema¬ 
tiche IEEE, FFP e per sfruttare la presenza dei coprocessori 
68881 0 68882. 

La chiamata diretta delle funzioni di library di Amiga può pro¬ 
durre significativi aumenti di velocità di esecuzione in qualsia¬ 
si programma. Nel corso dell’evoluzione del proprio 
compilatore, la Lattice ha tentato di migliorare le prestazioni 
evitando che le chiamate alle funzioni di sistema dovessero 
passare attraverso le routine di "interfacciamento" contenute in 
amiga.lib. Questo accorgimento permette di evitare il trasporto 
degli argomenti sullo stack (argomenti che, poi, venivano co¬ 
munque portati nuovamente nei registri appropriati dalle routi¬ 
ne di interfacciamento prima della chiamata vera e propria alla 
funzione). E ora possibile specificare al compilatore in quali 
registri vadano posti gli argomenti, lasciando quindi la possibi¬ 
lità al compilatore stesso di scegliere il metodo ottimale di ca¬ 
ricamento dei parametri nei registri. L’uso diretto delle 
funzioni di sistema è ottenuto grazie all'impiego di speciali file 
header presenti nel package. 

Funzioni e parole riservate 

La versione attuale del compilatore comprende diverse funzio¬ 
ni speciali "built-in", scritte con lo scopo di generare codice 
680x0 di alta qualità. L'uso di funzioni di questo è perfino in¬ 
coraggiato dallo stesso standard ANSI. Le funzioni speciali so¬ 
no abs, memset, putreg, strlen, max. memcmp. getreg, strcmp, 
min, memcpy, emit, strcpy e geta4. Il compilatore riconoscerà 
automaticamente una funzione "built-in" qualora il suo identi¬ 
ficatore sia preceduto da_builtin_. 

Vengono ora riconosciute diverse parole riservate, comprese le 
keyword a norme ANSI const, enum, void e volatile. Le parole 
riservate chip, far e near sono estensioni allo standard ANSI e 
dovrebbero essere precedute da due trattini; il compilatore Lat¬ 
tice, comunque, riconosce ambedue le forme. La più importan¬ 
te tra le parole riservate relative alla classe di memoria è la 
keyword chip (o meglio _chip), che permette di obbligare il 
compilatore a mettere l’oggetto a cui si riferisce nella memoria 
CHIP. In altri termini, ciò consente di scrivere definizioni del 
tipo: 

static USHORT chip GadgetlmageData[] = { 

0x7fff, 0x7fff, 0x7fff,0x7ff f,0x7fff,0x7fff,0x7fff, 
0x7fff,0x7fff,0x7fff,0x7fff,0x7fff,0x7fff,0x7fff, 
0x7fff, 0x7fff, 0x7fff,0x7f f f,0x7fff,0x7fff,0x7fff, 

0x7fff, 0x7fff,0x7fff,0x7fff,0x7fff,0x7fff,0x7fff, 

... e così via . . . 

} ; 


Inoltre, sono previste altre parole riservate da applicarsi a fun¬ 
zioni per specificare particolari convenzioni di passaggio dei 

parametri. Di una certa importanza sono_regargs e_stargs 

che indicano se si intende seguire una convenzione di passag¬ 
gio dei parametri basata sui registri o basata sullo stack. Viene 
anche messa a disposizione del programmatore tramite la paro¬ 
la riservata_asm la possibilità di specificare in quale registro 

passare un certo parametro (la maggior parte dei programmato- 
ri che hanno bisogno di una simile possibilità non esiteranno 
ad usare l’assembler). Personalmente mi domando se una simi¬ 
le possibilità sia realmente necessaria o addirittura auspicabile, 
ma può essere che non mi renda esattamente conto dei proble¬ 
mi che hanno giustificato la sua inclusione nel compilatore. 

Le utility "Compiler Companion" 

Non è passato molto tempo da quando la Lattice ha annunciato 
la disponibilità di un insieme di utility, che assistono il pro¬ 
grammatore nello sviluppo di programmi, raccolte sotto il no¬ 
me di "Compiler Companion". Alcune di queste sono state 
immesse sul mercato da parecchio tempo, ma dal momento che 
rimangono comunque utili, la Lattice ha deciso di includerle 
nel package di sviluppo. 

BUILD permette Linserimento o l'alternanza di linee di testo 
in un dato file. 

CXREF genera una cross-reference da un file sorgente C. Pro¬ 
duce tabelle in cui sono riportate definizioni, funzioni, etichette 
e così via e fornisce l’informazione necessaria per determinare 
dove esse compaiano nel programma. 

DIFF è una utility che consente di confrontare i file e di detre- 
minare le differenze tra essi. 

EXTRACT. come già il nome suggerisce, estrae i nomi di file 
da una directory. Questo comando viene spesso usato in asso¬ 
ciazione a BUILD per creare file batch per consentire di ese¬ 
guire automaticamente lunghe sequenze di comandi. 

FILES è un tool molto potente che permette di copiare, can¬ 
cellare o fare ricerche su file o intere directory. Può trattare an¬ 
che directory innestate una dentro l’altra e può limitare le 
operazioni di ricerca solo ai quei file che hanno una certa data 
di creazione o certe dimensioni. 

GREP sta per Global Regular Expression search and Print ov¬ 
vero utility di impiego generale per la ricerca e la stampa di 
espressioni regolari. Essa serve per ricercare sequenze di carat¬ 
teri specificate dall'utente secondo alcune regole ed è molto 
potente e versatile. Nel Development package sono state inse¬ 
rite le funzioni di ricerca impiegate nella utility in modo che 
l’utente possa servirsene liberamente nei propri programmi. 

LMK è una utility in tutto e per tutto simile alla utility "make" 
di UNIX; serve per stabilire le relazioni di dipendenza tra i file 
che costituiscono le varie parti di un progetto di grosse dimen¬ 
sioni, in modo tale che solo i moduli che sono stati cambiati e 
tutti quelli che dipendono da essi vengano ricompilati. Si rivela 
particolarmente comoda su sistemi dotati di hard disk, ma può 
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risultare molto utile anche in parecchi altre circostanze. 

GO è l’ottimizzatore globale; è, in altri termini, un programma 
che tenta di migliorare le prestazioni di un programma e, come 
potete immaginare, viene prevalentemente usato su programmi 
scritti da altri, piuttosto che sui propri. L’ottimizzatore opera 
sui file quad e controlla l’assegnamento dei registri, la presen¬ 
za di variabili che non vengono impiegate e così via. Analizza 
la disposizione del codice, individua sottoespressioni che ricor¬ 
rono varie volte nel programma, rimuove i calcoli invarianti al¬ 
l’interno dei loop (ma che cosa ci stanno a fare lì dentro, dico 
io!) ed esaminano altre possibilità di evitare calcoli inutili. Alla 
fine ciò che ottenete è un programma che funziona meglio o al 
più nella stessa maniera di quello originale e, stando così le co¬ 
se, non vedo che ragione ci possa essere per non usarlo. 

LPROF e LSTAT costituiscono il cosiddetto profiler. LPROF 
individua le zone del programma a cui viene passato il control¬ 
lo per la maggior parte del tempo e LSTAT elabora e rende 
leggibili i dati ottenuti da LPROF. Insieme, i due programmi 
possono fornire utili indicazioni su quali parti del programma 
possano trarre maggiore beneficio da speciali attenzioni. La 
Lattice deve aver usato parecchio queste due utility durante lo 
sviluppo della release 5.0. 

SPLAT è un sostanzialmente un editor di linea; è simile per 
certi versi a Ed, benché un po’ più sofisticato. 

TOUCH modifica la data di creazione di un file; viene usato 
generalmente da programmi che modificano in tale maniera in¬ 
teri insiemi di file. 

WC fornisce alcune statistiche sul contenuto di un file riguar¬ 
danti il numero di caratteri, parole e linee presenti. Può anche 
calcolare un checksum sui soli caratteri stampabili. Di questa 
utility è fornito anche il sorgente in modo tale che possa essere 
portata su altri sistemi se necessario. 

LSE, Lattice Screen Editor, è un altro programma molto como¬ 
do da usare. Esibisce caratteristiche specificamente rivolte ai 
programmatori C e assembler, come la presenza di un help on- 
line, dell’indentazione automatica e del ritorno a capo automa¬ 
tico. E possibile far eseguire automaticamente intere sequenze 
di operazioni associate a tasti e avere contemporaneamente 
aperti più file; inoltre sono disponibili molte funzioni di ricerca 
e sostituzione di stringhe. C’è anche la possibilità di definire 
delle macro per richiamare rapidamente le sequenze di coman¬ 
di o le stringhe usate più di frequente. 

Confrontando LSE con gli altri soliti editor, si evidenziano tre 
precisi vantaggi di questo editor rispetto alla concorrenza. In 
primo luogo, che vi piaccia o no, LSE è parte del package; in 
secondo luogo, è comodo perché sta insieme a tutte le altre uti¬ 
lity e, infine, è possibile chiamare il compilatore da LSE ed ot¬ 
tenere gli eventuali messaggi d’errore senza lasciare l’editor. 

Quest'ultima possibilità semplifica il ciclo di sviluppo di un 
programma e ne riduce sensibilmente i tempi morti. Bisogna 
poi notare, a completamento delle osservazioni precedenti, che 
LSE risulta ugualmente comodo per un programmatore assem¬ 


bler (vi ricordo che, nel kit di sviluppo, la Lattice ha messo an¬ 
che un ottimo assemblatore e tutti i file .i necessari). 

LCOMPACT è una utility per la compressione dei file header. 
Questo comando produce un file compattato in cui le parole ri¬ 
servate più comuni sono state codificate e gli spazi inutili e i 
commenti sono stati rimossi. Lcompact elabora anche la rap¬ 
presentazione delle costanti numeriche con il risultato di otte¬ 
nere file header di minori dimensioni e in una forma che il 
compilatore riesce a "digerire" più rapidamente. 

Tutti i file Header fomiti con il Lattice Development System 
5.0 sono disponibili sia in forma compressa che non compressa 
(e leggibile dagli umani!). 

C’è poi una gran quantità di programmi di supporto al pro¬ 
grammatore; di questi, mi limiterò a menzionare la presenza di 
una utility di traceback, che serve per analizzare le cause di un 
crash (ovvero di una visita del Guru). Questa utility, in unione 
ad una speciale routine di startup, permette di recuperare dati 
messi sullo stack durante l’esecuzione, il contenuto dei vari re¬ 
gistri e altre cose di questo genere, dopo che si sia verificata 
un’abend, cioè una terminazione anormale, del vostro pro¬ 
gramma. 

Tra le altre utility, si distingue fd2pragma, che converte i file 
FD della Commodore in istruzioni pragma impiegabili nei pro¬ 
pri programmi C. 

Debugging a livello di sorgente 

Per ultimo, certamente non in ordine di importanza, vorrei cita¬ 
re CodeProbe, il nuovo debugger a livello di sorgente della 
Lattice. Questo è senz’altro un programma molto interessante, 
perché permette di eseguire codice C compilato e di esaminar¬ 
ne il funzionamento a livello del sorgente. 

Per poter utilizzare CodeProbe su un vostro programma, è ne¬ 
cessario specificare una certa opzione al momento della compi¬ 
lazione, in modo che il linker includa nel modulo eseguibile 
tutte le informazioni necessarie al debugger per posizionare le 
linee di sorgente correttamente in relazione alle istruzioni del 
codice compilato e per accedere tramite il solo nome a tutti i 
simboli definiti nel programma. 

Quando si fa eseguire il programma, la linea di sorgente inte¬ 
ressata dall’esecuzione viene evidenziata. Le linee in cui c’è 
una chiamata a una funzione possono essere eseguite in un pas¬ 
so oppure si può entrare nella funzione e proseguire l’esecuzio¬ 
ne passo-passo al suo interno. Si possono disporre breakpoint 
(anche condizionali), si possono esaminare i contenuti delle 
variabili, dei registri del 68000 e di zone della memoria. 

Potete vedere contemporaneamente le linee di codice C e il lo¬ 
ro equivalente in assembler e controllare i valori assunti dalle 
variabile accedendo ad esse per nome. 


Continua a pagina 66 
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Introduzione a ROBBS 


Rexx Object Building Blocks - un progetto ARexx 


di Larry Philips 

ARexx è uno strumento molto potente su Amiga, in quanto per¬ 
mette ai programmi di comunicare fra di loro abbastanza fa¬ 
cilmente. In questo articolo, primo di una serie, Larry Philips 
descrive un'applicazione, ROBBS, che mette a disposizione 
una serie di blocchi, di mattoni da costruzione, per aiutare i 
programmatori a scrivere semplici programmi ARexx che con¬ 
trollino altri programmi esterni usati a loro volta come matto¬ 
ni da costruzione. Questo articolo descrive il concetto generale 
e presenta SerMod (modulo seriale), il primo modulo della se¬ 
rie, progettato per permettere alla porta seriale di comunicare 
con programmi compatibili ARexx. 

L’Amiga, per propria natura, incoraggia la scrittura di pro¬ 
grammi che si allontanano dai modelli normali. Su alcune mac¬ 
chine troviamo word processor integrati con database manager, 
spreadsheet e programmi di mailing list. Gli autori di questi 
programmi fanno grandi sforzi per fornire una serie nutrita di 
scelte e di funzioni e per integrare in maniera coerente le varie 
parti del pacchetto. 

Sui computer non multitasking troviamo, inoltre, tutta una se¬ 
rie di funzioni, contenute in programmi grandi e piccoli, che 
eseguono compiti molto semplici, quali la cancellazione di un 
file, la stampa del contenuto di una directory e così via. La ra¬ 
gione della presenza di queste funzioni è l’impossibilità di 
compiere tali operazioni a meno di non volere uscire dal pro¬ 
gramma in questione. 

Se avete mai cercato un programma particolare, o una serie di 
programmi, per aggiornare in maniera remota un database, uti¬ 
lizzando un modem, vi sarete probabilmente rassegnati al fatto 
che gli unici programmi che avete trovato potevano svolgere 
questo lavoro solo in modo batch (esecuzione di una serie di 
comandi contenuti in un file), dopo la fine delle ore di attività 
lavorativa, mentre il vostro programma di database era inatti¬ 
vo. 

Ebbene, noi possessori di Amiga sappiamo che c’è un modo 
migliore e abbiamo la macchina per risolvere questo tipo di 
problemi. 

Per il fatto che Amiga è una macchina multitasking, non ci so¬ 
no ragioni sufficienti perché un autore debba includere nel pro¬ 


prio programma quelle funzioni che sono svolte meglio da altri 
programmi. Il nostro programma di terminale, per esempio, 
non deve per forza incorporare una funzione per ottenere il 
contenuto di una directory, perché è così semplice passare nel 
CLI (o aprirne un altro) per eseguire l’operazione. In realtà, un 
nostro semplice programma di terminale è molto più potente, o 
perlomeno è potenzialmente molto più potente di qualsiasi al¬ 
tro analogo che possiate trovare su altre macchine. Possiamo 
lanciare virtualmente qualsiasi programma mentre siamo in li¬ 
nea, ottenendo un grado di libertà e di flessibilità che sulle 
macchine inferiori può essere solamente sognato. 

Sebbene questa capacità sia molto importante, esiste un altro 
livello di versatilità che, fino a questo momento, è rimasto ine¬ 
splorato. E bello poter eseguire più programmi nello stesso 
momento, ma non sarebbe ancora più bello se potessimo usare 
qualsiasi programma con qualsiasi altro programma, come se 
questi fossero stati scritti per lavorare assieme? 

Oggi questo non è possibile, perlomeno non con tutti i pro¬ 
grammi esistenti, ma potrebbe esserlo in futuro. Ho sentito un 
possessore di Amiga dire "database, word processor e animator 
tutti collegati insieme... potrebbero fare sparire HyperCard dal¬ 
la vergogna." Personalmente non riesco a pensare a un utilizzo 
pratico di questi tre programmi integrati, ma il fatto è che qual¬ 
cuno ha pensato che ciò sarebbe meraviglioso. 

Dubito che l’autore di un qualsiasi database possa anche solo 
considerare l'eventualità di scrivere il codice per permettere al 
suo programma di scambiare dati con gli altri due e la stessa 
cosa vale per gli altri due autori. Anche se questi pensassero 
che è una buona idea, quale programma dovrebbero scegliere 
per mettere in pratica il collegamento? Se il prescelto fosse un 
programma a noi particolarmente gradito ne saremmo felici, 
ma in caso contrario continueremmo ad augurarci che avessero 
scelto il nostro favorito. 

Questi pensieri mi hanno portato all'idea che quello di cui ab¬ 
biamo realmente bisogno sono una serie di mattoni da costru¬ 
zione progettati per essere collegati insieme e contenenti 
ognuno una serie, limitata ma necessaria, di funzioni. 

Non posso, comunque, prendermi il merito per l’idea di base. 
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Questa è una filosofia che ha resistito alla prova del tempo in 
un buon numero di sistemi operativi. UNIX è uno di questi, e, 
anche se non lo amate in modo particolare, dovete comunque 
ammettere che la possibilità di costruire programmi complessi 
partendo da programmi piccoli e semplici è un’idea molto vali¬ 
da. 

Ad ogni modo, personalmente voglio andare un gradino più in 
là e scrivere una serie di moduli che possano essere controllati 
più in dettaglio. Mentre Unix permette la manipolazione dei 
programmi attraverso stdin , stdout, pipe, redirezione e file in¬ 
termedi, io intendo entrare nell’essenza dei piccoli programmi 
e permetterne una manipolazione più diretta. 

I messagi fra programmi 

Amiga dispone di una funzione interna che risulta ideale per i 
nostri scopi. Può inviare messaggi fra programmi attraverso un 
sistema di porte apposite (message port). 

II funzionamento di una message port è molto semplice. Un 
programma può creare una message port, assegnarle un nome e 
renderla pubblica inserendola in una lista di sistema. Una volta 
fatto questo, qualsiasi altro programma può cercare una porta 
con un certo nome e, in caso questa sia trovata, spedirle un 
messaggio. 

Il messaggio viene ricevuto dalla porta e il programma che ha 
creato la porta può fame ciò che desidera. Il programma rice¬ 
vente deve essere, naturalmente, in grado di comprendere il 
messaggio. A questo punto il ricevente risponde al messaggio 
per fare sapere al programma mittente che il suo messaggio è 
stato ricevuto e per permettere che il mittente riutilizzi come 
meglio crede la zona di memoria occupata dal messaggio stes¬ 
so. 

I messaggi e ARexx 

Prima dell’avvento di ARexx, la capacità di Amiga di scambia¬ 
re messaggi era limitata a programmi compilati in una serie di 
linguaggi differenti e quindi fuori portata per molti utenti. 
ARexx, invece, sfrutta appieno questa potenzialità e può man¬ 
dare messaggi ad altri programmi ARexx (script) oppure a pro¬ 
grammi (eseguibili) progettati per comprendere i messaggi di 
ARexx. 

Questo apre nuovi orizzonti a coloro che amano i linguaggi in¬ 
terpretati, permettendo la scrittura di semplici programmi (non 
così semplici) ARexx che chiamano altri programmi come 
mattoni da costruzione, in una sorta di construction set per pro¬ 
durre applicativi. 

Dopo mesi di discussioni con altri programmatori su questa 
idea e non essendo capace di interessarli a sufficienza tanto da 
convincerli a iniziare a scrivere i moduli, ho cominciato a scri¬ 
verne qualcuno personalmente. 

Ho chiamato questa serie di moduli ROBBS, abbreviazione di 
Rexx Object Building Block System (sistema Rexx di costru¬ 
zione a mattoni). 


Il modulo seriale SerMod 

Il primo modulo della serie si chiama SerMod (da Serial Mo- 
dule). E stato progettato per essere piccolo (circa 12K, ma può 
essere reso ancora più piccolo) e per contenere un numero li¬ 
mitato di funzioni che sono indispensabili esclusivamente per 
l'uso della porta seriale. 

Quando è nato era una combinazione di funzioni per la porta 
seriale e per il display, ma appena la parte seriale ha incomin¬ 
ciato a lavorare in modo soddisfacente, ho separato la parte che 
riguardava il display e con quella ho creato un altro modulo 
chiamato (avete indovinato) DispMod. DispMod è un semplice 
programma di display che dispone di un solo tipo di finestra e 
di una funzionalità limitata all’elaborazione degli input e alla 
gestione degli output. 

SerMod in sé stesso è abbastanza limitato. Potete lanciarlo da 
uno script e mandargli dei comandi da quello stesso script per 
compiere una serie di azioni disparate, quali settare i parametri 
della porta seriale, spedire del testo, ricevere del testo e con¬ 
frontare i dati entranti con le stringhe fornite dall’utente. 

Con uno script appropriato potrebbe funzionare come utility 
per il trasferimento di file, come una BBS o come un program¬ 
ma per permettere operazioni tipo CUI a distanza (in maniera 
limitata). 

La combinazione di uno script, di SerMod e di DispMod di¬ 
venta, invece, un programma di terminale abbastanza potente. 
Quando dico abbastanza potente, mi riferisco alle possibilità 
che si hanno con uno script di ARexx, dal momento che il mo¬ 
dulo dei protocolli, il modulo dei menu, il modulo dei gadget e 
così via devono ancora essere implementati! 

Ho scelto di scrivere prima SerMod perché molti programmi 
possono trarre beneficio dalla possibilità di effettuare comuni¬ 
cazioni attraverso la porta seriale e perché non è difficile im¬ 
maginare i modi in cui si può combinare un modulo seriale con 
altri programmi. 

SuperBase viene adesso fornito con un’interfaccia ARexx, così 
come MicroFiche Filer. Anche CygnusEd Professional, TxEd, 
Uedit, DME. PCLO e PCLO Plus sono dotati di interfaccia 
ARexx. 

Con SerMod e uno script ARexx, uno qualsiasi di questi pro¬ 
grammi acquista improvvisamente la capacità di comunicare 
attraverso la porta seriale, via cavo in ambito locale e via mo¬ 
dem in ambito remoto. Se si crea abbastanza interesse in que¬ 
sto progetto, verranno indubbiamente scritti molti altri moduli, 
piccoli programmi che fanno solo poche operazioni e che ci 
permetteranno di costruire altri applicativi. Anche coloro che 
non desiderano programmare, nemmeno in ARexx, possono 
trarre beneficio dai programmi ARexx scritti per ROBBS. 

Cos’è esattamente ROBBS? 

Forse è il caso di dire due parole sulla filosofia che sta dietro a 
ROBBS. 
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Una tipica applicazione di ROBBS consisterà in uno o più mo¬ 
duli ROBBS, controllati da uno o più script ARexx. In aggiun¬ 
ta, potrebbero essere chiamati anche dei programmi esterni, sia 
che abbiano un'interfaccia ARexx o meno. Qualsiasi program¬ 
ma che può fornirci i dati che ci interessano, magari in un file, 
può essere usato in questo contesto. 

Ogni modulo ROBBS usato in un applicativo dovrà compiere 
solo poche operazioni, per mantenere limitate le dimensioni, 
per semplificare la programmazione e per assicurare che ci sia 
il minor spreco di sforzo che usualmente si verifica quando 
vengono implementate le stesse funzioni in moduli diversi. So¬ 
lo quei comandi che hanno senso in quel determinato contesto 
devono essere creati. 

Per il motivo precedente, non c’è bisogno di definire una serie 
di comandi standard che accomunino tutti i moduli, anche per¬ 
ché è abbastanza facile modificare i programmi di controllo 
ARexx per adeguarsi alle eventuali differenze. Ci sono alcuni 
comandi che hanno senso in tutti i moduli e questi dovrebbero 
essere chiamati tutti con lo stesso nome. Alcuni esempi sono 
STATUS, CONNECT, CTRL e DIE (ne parleremo più avanti). 

A questo punto vorrei darvi l’idea di come dovrebbe apparire il 
tipico modulo dal punto di vista di un programmatore ARexx. 
Utilizzerò SerMod come esempio. Sebbene sia già stato scritto, 
non è ’scolpito nella pietra’. Se avete qualsiasi suggerimento 
per l’aggiunta di altre funzioni, non esitate a contattarmi. 

I comandi SerMod 

RXD abilita o disabilita la ricezione di dati seriali. 

Permette agli altri programmi che aprono la porta seriale in 
modo SHARED di avere accesso ad essa senza interferenze. 

Accetta ON o OFF come argomenti. 

TXD abilita o disabilita la trasmissione di dati seriali. 

Permette a un altro programma di spedire dati senza alcuna in¬ 
terferenza da parte di SerMod. L’altro programma deve aprire 
la porta seriale in modo SHARED. 

Accetta ON o OFF come argomenti. 

SEND manda una stringa sulla porta seriale. 

Una variante di questa funzione, chiamata LSEND, manda una 
stringa facendola seguire da un carattere di Carriage Return. 

Accetta una stringa come argomento. 

MATCH prepara e passa a SerMod una stringa di paragone 
che deve essere ricercata nei dati che arrivano dalla porta seria¬ 
le. 

Quando SerMod trova questa stringa nel flusso di dati entrante, 
manda un messaggio alla porta CTRL, specificando il numero 
della stringa che è stata trovata. SerMod permette infatti la de¬ 


finizione di 10 stringhe di 100 caratteri Luna. Il comando 
MATCH può essere eseguito quante volte si vuole, per permet¬ 
tere la sostituzione delle stringhe di paragone specificate in 
precedenza. MATCH permette anche la cancellazione selettiva 
o totale delle stringhe di paragone. Notate che la funzione 
SCAN deve essere attiva affinché il comando MATCH abbia 
effetto. 

Accetta un numero compreso fra 0 e 9, seguito da una stringa. 
Per esempio: 

MATCH 3 'Questa è una stringa' 

SCAN abilita la funzione di ricerca delle stringhe di paragone 
preparate con MATCH. 

Accetta ON o OFF come parametri. 

CONNECT collega il flusso di dati ricevuti a una specifica 
message port. 

Permette anche di stabilire il comando che verrà usato per spe¬ 
dire i dati, dal momento che non tutti i moduli utilizzano lo 
stesso. Si possono mandare i dati entranti allo script di control¬ 
lo, oppure direttamente a un altro modulo ROBBS. 

Accetta due argomenti, il nome di una porta e un comando. 

CTRL collega SerMod a un’altra porta per motivi di controllo. 

Qualsiasi programma può mandare messaggi a SerMod, men¬ 
tre quest’ultimo manda il flusso di dati entranti alla porta 
CONNECT e le eventuali stringhe di paragone trovate nel flus¬ 
so alla porta di controllo CTRL. Questo significa che possiamo 
passare il controllo da uno script a un altro script, come meglio 
crediamo. 

Accetta il nome di una porta come argomento. 

COMM modifica i parametri della porta seriale. 

Permette di stabilire il baud rate, il modo (echo, noecho), lo 
handshaking e il formato dei dati (7 o 8 bit). 

Gli argomenti di questa funzione verranno spiegati meglio in 
una successiva trattazione dettagliata dei comandi. 

DIE libera le risorse allocate e rimuove SerMod dal sistema. 

Se tutti i messaggi spediti da SerMod hanno ricevuto una ri¬ 
sposta, questa operazione viene effettuata immediatamente. Se 
c’è ancora qualche messaggio che non ha ricevuto risposta, 
viene stampato un avviso nel CLI dal quale SerMod è stato 
lanciato e l’utente deve dare il comando REALLY_DIE per ri¬ 
muovere SerMod. Questo eventualità non dovrebbe mai acca¬ 
dere in un applicativo già testato e corretto e viene fornita solo 
come uscita di emergenza per quando uno script si interrompe 
a causa di un errore. 

Non richiede argomenti. 
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SE CERCHI 

IL TUO MIGLIORE AMICO, 
CERCALO IN UN CANILE 


E di amici a quattro zampe ne troverai 
non uno, ma migliaia. Sono i cani abban¬ 
donati ospitati presso i Canili della Lega. 
Cani che un tempo avevano un nome e 
un padrone, cani che adesso hanno solo 
paura. Paura di finire i loro giorni 
dietro le sbarre, senza mai più sen¬ 
tire la carezza di un uomo. Perciò, 
se cerchi un amico, cercalo in un 


canile: ti sta aspettando. Per maggiori in¬ 
formazioni telefona allo 010/561557. Se in¬ 
vece non puoi adottarne uno, puoi fare co¬ 
munque molto per loro, inviando un’of¬ 
ferta in denaro sulCCP 17182122. Il tuo 
aiuto servirà a tenere in vita la spe¬ 
ranza che un giorno possa rico¬ 
minciare una storia d’amore senza 
fine: quella tra l’uomo e il suo cane. 



CC P17182122 • UFFICIO PROPAGANDA E SVILUPPO • VIA GIANOLIO 31/4 12042 BRA 

TEL 010/561557 
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STATUS restituisce una stringa contenente lo stato attuale di 
SerMod. 

La stringa contiene informazioni sulle regolazioni della porta 
seriale, sullo stato di SCAN, TXD e RXD, sulle porte CON- 
NECT e CTRL e, per usi futuri, contiene l'indirizzo della strut¬ 
tura IOSerRequest che SerMod sta utilizzando. 

Non richiede argomenti. Il formato della stringa restituita verrà 
descritto in una successiva trattazione dettagliata dei comandi. 

Articoli futuri 

Prevedo di pubblicare il codice sorgente di SerMod in uno dei 
prossimi numeri, insieme ad alcuni esempi di programmi 
ARexx e alle spiegazioni di come usare SerMod. 

Nel frattempo ponderate quanto detto in questa puntata, in mo¬ 
do particolare riguardo la versatilità del collegare più program¬ 
mi attraverso ARexx e lasciate correre la vostra 
immaginazione. 

Nei mesi a venire scriverò almeno uno o due altri moduli, ma¬ 
gari anche di più, e presto saremo ben avviati sulla strada che 
ci porterà a disporre di alcuni dei più veloci ed efficienti appli¬ 
cativi che possiate immaginare. 

□ 

(segue da pagina 61) 

Lattice C 5.0 

Le opzioni sono così tante che potremmo neanche sperare di 
menzionarle tutte; per rendersene conto, basta osservare che la 
documentazione relativa a CodeProbe costituisce circa un terzo 
del secondo manuale. 

Bisogna ammettere che CodeProbe è un programma che si usa 
in maniera molto piacevole e che, al tempo stesso, può soddi¬ 
sfare anche gli utenti professionali. Non si può certo affermare 
con assoluta certezza che sia privo da errori e da problemi di 
varia natura, anzi è probabile che con la diffusione del suo uso 
se ne evidenzino più d’uno, ma tutto concorre a dare l’impres¬ 
sione che il programma rimarrà comunque molto utile. 

Conclusioni 

In definitiva, la versione 5.0 del Lattice Development System è 
un pacchetto software dalle caratteristiche molto professionali. 
Certamente procurerà molti nuovi clienti alla Lattice, soprattut¬ 
to per il buon rapporto prestazioni-prezzo. Non che sia partico¬ 
larmente economico, intendiamoci; piuttosto, bisogna conside¬ 
rare il fatto che viene fornita una gran quantità di software e 
una eccellente documentazione e non credo che si possa dire 
che il prezzo è elevato per tutto quello che viene offerto. Gli 
utenti registrati Lattice potranno poi ottenere la nuova release 
per un prezzo molto inferiore al valore del solo CodeProbe. 


(segue da pagina 28) 

Breakpoint 

MS permette di mischiare la visualizzazione di linee del codice 
sorgente con il loro disassemblato in memoria, in modo da per¬ 
metterci di vedere cosa fa il nostro compilatore. Selezionare 
una linea del codice sorgente è come selezionare l’indirizzo 
della prima istruzione del codice generato per quella linea. 

Ebbene, abbiamo più o meno visto quali sono le differenze fra 
i debugger. Che vi piacciano le finestre e il poter puntare e se¬ 
lezionare con il mouse o che preferiate lavorare in un ambiente 
testuale, questo dipende dal vostro gusto personale. Io penso 
che l’avere una zona di memoria costantemente visualizzata sia 
una caratteristica estremamente utile, ma sono sicuro che ci 
siano altri che preferiscono l’esecuzione di 'liste di comandi’ a 
ogni breakpoint. 

In conclusione 

Spero che vi sia piaciuto leggere questa serie di articoli. Io mi 
sono divertito a scriverli. Forse dopo che MetaScope verrà reso 
completamente compatibile con il codice sorgente e l’Avant- 
Garde avrà finito il suo debugger M2, daremo ancora un’oc¬ 
chiata alle innovazioni presenti nel campo del debugging e alle 
sue ultime novità. Presumo che Lattice e Manx avranno, per al¬ 
lora, prodotto delle versioni più avanzate dei loro CPR e SDB. 

Ho tentato di non essere troppo dogmatico in questa serie di ar¬ 
ticoli. La mia esperienza con molti sistemi, debugger e pro¬ 
grammatori mi dice che ogni persona deve trovare il suo stile, 
quello con il quale si trova meglio. Il debugging è ancora 
un’arte in molti sensi della parola e se voi vi trovate bene con 
una determinata tecnica, allora per voi funzionerà benissimo. 
Se non siete contenti di quella tecnica, potrà solo ostacolarvi. 

Vorrei lasciarvi con qualcosa che mi ha aiutato più di ogni al¬ 
tra cosa nel mio debugging: 

Abbiate sempre qualche idea di che cosa vi state aspettando 
prima di fare una prova. 

Egli saltò alla sua tastiera 
Un ultimo break da inserire 
Ma cominciò a svanire 

Sembrava molto sottile 

E lo sentii esclamare 

prima che sparisse di vista 
'Buon debugging a voi tutti... 

Fategliela vedere a quel GURU!' 


□ 
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I device handler 


Come creare un device handler per AmigaDOS 


di Steve Simpson 

Steve Simpson è un esperto di software in ambito Amiga e PC. 
Un ex-astronomo, Steve ora traduce documentazione tecnica 
dallo svedese; i suoi attuali interessi riguardano lo sviluppo di 
sistemi e di firmware. Al momento si sta occupando del miglio¬ 
ramento delle routine di interfacciamento del SideCar, relati¬ 
vamente al pacchetto software che dovrebbe essere disponibile 
alla fine del 1989. Steve è anche l'autore di DiskRepair, una 
utility per /' editing dei dischi e il recupero di file danneggiati. 

Tutti coloro i quali impiegano il CLI o il WorkBench saranno 
certamente familiari con l'AmigaDOS e il filing System. Sia il 
CLI sia il WorkBench fanno per forza di cose un uso intensivo 
dei comandi messi a disposizione dalTAmigaDOS. Il nome di 
"filing System" si applica solamente ai dispositivi che appaiono 
con un’icona nella finestra del WorkBench e che generalmente 
corrispondono a disk drive; ci sono, però, anche altri tipi di di¬ 
spositivi, detti "non-filing", disponibili sotto AmigaDOS, come 
PRT:, SER:, RAW: e CON:. L'insieme dei "device" disponibili 
non è fisso e può essere ampliato secondo le necessità. 

Questo articolo è il terzo di una serie che ha avuto origine da 
un progetto di grandi dimensioni nel quale sono attualmente 
impegnato; intende trattare il progetto e Y implementazione di 
un device handler in AmigaDOS e ha lo scopo di chiarire un 
argomento che, nella documentazione ufficiale, viene trattato 
in maniera molto approssimativa. 

Che cos’è un device di Amiga? 

Il termine "device" neH’ambiente Amiga si riferisce a due og¬ 
getti distinti. Ci sono device Exec, quelli cioè che troviamo 
nella directory DEVS: con il suffisso .device, a cui è affidato il 
compito di occuparsi delle richieste di I/O verso i dispositivi 
hardware veri e propri (device Exec tipici sono il keyboard.de- 
vice e il trackdisk.device) e ci sono i device DOS, altrimenti 
detti handler. 

Per evitare malintesi, sappiate che, in questo articolo, la dizio¬ 
ne System device si riferisce a un device Exec, mentre i termini 
DOS device, DOS device handler e DOS handler sono tutti si¬ 
nonimi. 

I device DOS forniscono al sistema la possibilità di interagire 


in maniera omogenea con i differenti dispositivi del mondo 
esterno. I device DOS vengono trattati come se fossero file, 
impiegando chiamate a funzioni DOS come Open(), Close(), 
Read() e Write(); è poi compito dello specifico handler tradur¬ 
re queste chiamate nelle opportune sequenze di operazioni, 
specifiche della particolare implementazione. Più precisamen¬ 
te, un handler rappresenta in generale, l’interfaccia tra il DOS e 
un device Exec; un device DOS può, infatti, servirsi dei device 
Exec per effettuare le operazioni di I/O richieste e, in effetti, 
questo è ciò che succede nella maggior parte dei casi (ad es. 
SER: apre il serial.device e DFO: usa il trackdisk.device): 

Un device DOS viene aperto con la chiamata: 

file_handle = Open(nome_di_device,modo); 

dove: 

file_handle è un puntatore a una struttura FileHandle, definita 
in libraries/dosextens.h 

nome di device è una stringa di caratteri che specifica il no¬ 
me del device (CON:, RAW:, etc.) 

modo è un intero long che specifica il modo; MODE_NEWFI- 
LE apre un device sia per la lettura sia per la scrittura. 

La chiusura di un device precedentemente aperto viene effet¬ 
tuata con la funzione 

Close(file_handle); 

I pacchetti e l’AmigaDOS 

Le comunicazioni tra i programmi applicativi e il DOS avven¬ 
gono tramite l’invio di pacchetti, grazie alle possibilità di 
"message passing" messe a disposizione dall’Exec. Un pac¬ 
chetto è una struttura costruita estendendo la struttura Message 
dell’Exec ed è definita in dosextens.h nella seguente maniera: 


struct 
{ 

struct 


DosPacket 


Message 


*dp_Link; 
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struct MsgPort 

*dp Port; 

nita nel file libraries/ dosextens.[hi]; gli altri tipi di pacchetto 

LONG 

dp_Type; 

ufficialmente riconosciuti sono comunque riportati nel file 

LONG 

dp_Resl; 

new-handler.h. che potete trovare al termine di questo articolo 

LONG 

dp Res2; 

insieme con gli altri listati. 

LONG 

dp Argl; 


LONG 

dp Arg2; 

Le strutture dati del DOS 

LONG 

dp Arg3; 


LONG 

dp Arg4; 

Il DOS impiega un cello numero di strutture dati per i propri 

LONG 

dp Arg5; 

scopi; la definizione di tali strutture è riportata nel file libra- 

LONG 

dp_Arg6; 

ries/dosextens.fhi]. Esaminiamole in dettaglio. 

LONG 

dp Arg7; 


}; 


struct DosLibrary 


Il formato di un pacchetto dipende dal tipo e da quest'ultimo 
dipendono anche gli argomenti (Argl - Arg7) effettivamente 
usati. Un’applicazione scritta dall'utente può anch'essa inviare 
pacchetti a un handler, ma non ci occuperemo di questo aspetto 
in questo articolo. 

I pacchetti DOS vengono inviati al message port dello handler, 
port che è automaticamente creato dal sistema come parte della 
struttura che descrive il processo. Il message port è inizializza- 
to in modo che l'arrivo di un messaggio causi l’attivazione del 
segnale 8. Questo fa sì che si possa richiamare la funzione di 
Exec Wait() (relativamente al segnale 8) per attendere l’arrivo 
di un pacchetto dal DOS. 

Con la funzione GetMsgO si rimuove il messaggio dal port; 
l’indirizzo del pacchetto viene, quindi, preso dal campo ln_Na- 
me della struttura Node contenuta nel messaggio; il tipo di 
azione da effettuare viene invece specificato nel campo dp_Ty- 
pe del pacchetto. 

Quando lo handler ha terminato di compiere le operazioni ri¬ 
chieste dal pacchetto, lo restituisce attraverso una chiamata a 
PutMsgQ, passando la medesima struttura. 

Al momento attuale ci sono almeno due dozzine di tipi di pac¬ 
chetto ufficialmente definiti, ma non tutti possono essere man¬ 
dati a qualunque handler. Inoltre, è anche opportuno osservare 
che gli argomenti assumono un significato diverso a seconda 
del tipo di pacchetto. 

Resi viene posto a zero di norma per segnalare un errore e in 
tal caso Res2 fornisce maggiori dettagli in merito al tipo del¬ 
l’errore (il valore di Res2 è quello che si ottiene chiamando la 
funzione IoErrQ). Un -1 in Resi, invece, indica il completa¬ 
mento con successo delle operazioni richieste qualora il pac¬ 
chetto inviato usi questo campo per comunicare la presenza di 
errori. 

Gli argomenti possono essere sia interi long sia puntatori 
BCPU e in quest'ultimo caso possono presentarsi sia puntatori 
a stringa (BSTR) che puntatori a struttura (BPTR). Le differen¬ 
ze tra un puntatore C e uno BCPL saranno esaminate in detta¬ 
glio più avanti. 

La tavola 1 descrive brevemente l’impiego e il significato dei 
vari campi della struttura DosPacket al variare del tipo (specifi¬ 
cato in dp_Type). La maggior parte dei tipi di pacchetto è defi- 


{ 

struct 

APTR 

APTR 

LONG 

LONG 

LONG 


Library 


dl_lib; 
dl_Root; 
dl_GV; 
dl_A2; 
dl_A5; 
di A6; 


dl_lib: una struttura Library, che costituisce un nodo della lista 
delle library presenti nel sistema. 

dIRoot: un puntatore alla struttura RootNode. 

dl_GV : un puntatore al "global vector" (usato col BCPL). 

dl_A2, dl_A5 e dl_A6: campi usati per tenere copie tempora¬ 
nee dei registri. 

La struttura RootNode è definita nella maniera seguente: 


struct RootNode 
{ 

BPTR 
BPTR 
struct 
LONG 
BPTR 
BPTR 


DateStamp 


rn_TaskArray; 
rn_ConsoleSegment; 
rn_Time; 
rn_RestartSeg; 
rn_Info; 

rn_FileHandlerSegment; 


rn_TaskArray: un array che specifica i processi CLI già atti¬ 
vi. 

rn ConsoleSegment: la SegList relativa al CLI. 
rnTime: l’ora attuale. 

rn_RestartSeg: la SegList per il "disk validator". 
rn_Info: un puntatore BCPL a una struttura Doslnfo. 

La struttura Doslnfo è così definita: 

struct Doslnfo 


BPTR 

BPTR 


di_McName; 
di Devlnfo; 
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BPTR 
BPTR 
APTR 
} ; 


di_Devices; 
di_Handlers ; 
di NetHand; 


diMcName: il nome di questa macchina nella rete (per il mo¬ 
mento questo campo è posto a zero). 

di_DevInfo: un puntatore BCPL alla lista dei device e dei vo¬ 
lumi disponibili. 

di_Devices: per il momento, zero. 

di Handlers: per il momento, zero. 

di_NetHand: il process ID dello handler della rete. 

L'AmigaDOS si preoccupa di gestire e mantenere aggiornata 
una lista di strutture che descrivono i "device" fisici, quelli vir¬ 
tuali (quelli, cioè, creati con ASSIGN) e i vari volumi disponi¬ 
bili; per specificare a quale di questi tre tipi di oggetti si 
riferisce una certa struttura della lista viene impiegato un cam¬ 
po che può assumere uno tra i valori DLT_DEVICE. DLT_D1- 
RECTORY e DLT_VOLUME rispettivamente. 

Il formato di un elemento della lista dipende dal tipo di oggetto 
a cui tale elemento si riferisce. Un device o una directory viene 
descritta con la struttura Devlnfo, che è così costituita: 


struct 

{ 

BPTR 

LONG 

APTR 

BPTR 

BSTR 

LONG 

LONG 

LONG 

BPTR 

BPTR 

BSTR 


Devlnfo 


dvi_Next; 

dvi_Type; 

dvi_Task; 

dvi_Lock; 

dvi_Handler; 

dvi_StackSize; 

dvi_Priority; 

dvi_Startup; 

dvi_SegList; 

dvi_GlobVec; 

dvi Name; 


dvi_StackSize: dimensioni dello stack associato al processo 
dello handler. 

dviPriority: priorità del processo dello handler. 

dviStartup: valore di inizializzazione da passare al processo 
dello handler. 

dvi_SegList: puntatore BCPL alla "segment list" del processo 
dello handler oppure zero. 

dviGIobVec: puntatore BCPL al "global vector" del processo 
dello handler oppure zero. 

dviName: nome del device fisico o virtuale. 

Se il campo dvi_Type contiene il valore DLT_VOLUME (2L), 
l’elemento della lista descrive un volume e viene impiegata la 
seguente struttura: 


struct 

/ 

DeviceList 


\ 

BPTR 


di Next; 

LONG 


di Type; 

struct 

MsgPort 

*dl Task; 

BPTR 


di Lock; 

struct 

DateStarap 

di VoluraeDate; 

BPTR 


di LockList; 

LONG 


di DiskType; 

LONG 


di unused; 

BSTR 

}; 


di Name; 


Il significato dei campi è il seguente: 

dvi_Next: puntatore al prossimo elemento della lista. 

dvi_Type: tipo dell’oggetto a cui questa struttura si riferisce; 
in questo caso può essere solo DLT_DIRECTORY (IL) o 
DLT_DEVICE (OL). 

dvi_Task: process ID del processo dello handler, se abbiamo a 
che fare con un device, altrimenti zero. 

dvi Lock: puntatore BCPL a un lock del file System oppure 
zero. 

dvi Handler: nome del file dello handler oppure zero. 


in cui i campi hanno il seguente significato: 

dl_Next: puntatore al successivo elemento della lista. 

dIType: tipo dell’oggetto a cui si riferisce questa struttura; in 
questo caso non può essere che DLTJVOLUME (2L). 

dl_Task: process ID dello handler del dispositivo su cui è 
montato il volume a cui si riferisce la struttura, altrimenti zero. 

dl_Lock: puntatore BCPL ad un lock del file System. 

dl_VolumeDate: data di creazione del volume. 

dl_LockList: puntatore BCPL alla lista di lock attivi relativi a 
questo volume. 

dlDiskType: tipo del disco su cui risiede il volume. 

dl_Name: puntatore a stringa BCPL che specifica il nome del 
volume. 

La struttura Devlnfo è equivalente alla struttura DeviceNode 
definita in libraries/filehandler.[hi]: 

struct DeviceNode 
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BPTR 


dn Next; 

ULONG 


dn Type; 

struct 

MsgPort 

*dn Task; 

BPTR 


dn Lock; 

BSTR 


dn Handler; 

ULONG 


dn StackSize; 

LONG 


dn_Priority; 

BPTR 


dn Startup; 

BPTR 


dn SegList; 

BPTR 


dn GlobalVec; 

BSTR 


dn Name; 


} ; 


I puntatori BCPL 

II BCPL è stato un precursore del C che consentiva l'uso di un 
solo tipo di variabile: la long word. Per questa ragione tutto in 
BCPL veniva allocato a partire da indirizzi multipli di quattro 
(il numero di byte di una long word). 

È importante ricordare, quando dovete allocare una stringa 
BCPL o un qualsiasi altro oggetto a cui si debba accedere con 
un puntatore, che usando la funzione della libreria Exec Alloc- 
Mem() si può star tranquilli che il blocco ottenuto soddisfi la 
condizione di allineamento a un multiplo di quattro dalla quale 
in BCPL non si sfugge. 

Dal momento che il BCPL usa solo long word, anche i punta¬ 
tori sono long word e vengono detti BPTR. Ciò che complica 
la situazione è che non sono semplici puntatori perché non 
contengono l'indirizzo effettivo in memoria, ma l’indirizzo di¬ 
viso per 4. Potete ora comprendere che è assolutamente obbli¬ 
gatorio allocare i blocchi di memoria in modo che il loro 
indirizzo sia un multiplo intero di 4. 

Le stringhe BCPL sono diverse dalle stringhe C. La stringa 
BCPL, detta più brevemente BSTR, è una struttura in cui il pri¬ 
mo byte contiene la lunghezza della stringa e i successivi i ca¬ 
ratteri della stringa stessa. 

In generale si accede a una stringa BCPL tramite un BPTR. Per 
ottenere da un puntatore C l’equivalente puntatore BCPL biso¬ 
gna "shiftare” il valore del puntatore di due bit verso destra: 
analogamente, per convertire da BCPL si "shifta" a sinistra di 
due bit. Le macro CPTRtoBPTRO e BPTRtoCPTR(), impiega¬ 
te nell'esempio che accompagna questo articolo, effettuano le 
conversioni richieste. 

I lock 

A un processo che presenta una richiesta di apertura di un file 
viene generalmente concesso un certo tipo di accesso esclusivo 
al file in questione. L'accesso può essere allora condiviso o 
esclusivo del processo che ha fatto la richiesta. In tal caso il si¬ 
stema passa al processo un cosiddetto "lock" sul file. Un lock 
rappresenta un identificatore univoco di un file ed è una forma 
più semplice di descrittore di file: può essere ottenuto nella 
maniera seguente: 

file lock = Lock(file name,mode); 


dove: 

filelock è un puntatore a una struttura FileLock, definita nel 
file libraries/dosextens.h. Viene restituito uno OL se si è verifi¬ 
cato un eiTore. 

file_name è una stringa C contenente l’intero path e il nome 
del file. 

mode specifica il tipo di accesso richiesto: 

ACCESS_READ fornisce accesso condiviso, 
ACCESS_WRITE fornisce accesso esclusivo. 

La funzione 

UnLock(file_lock) 

rilascia un lock precedentemente ottenuto. 

La struttura FileLock è così definita: 


struct 

/ 

FileLock 


\ 

BPTR 


fl_Link; 

LONG 


fi Key; 

LONG 


fi Access 

struct 

MsgPort 

*fl_Task; 

BPTR 


fi Volume 


Il significato dei membri che possono interessare all’utente è il 
seguente: 

fi Kev: il numero del blocco sul disco a cui ha inizio il file. 

fl Access: tipo di accesso al file (ACCESS_READ o AC- 
CESS_WRITE). 

fl_VoIume: puntatore al descrittore del volume associato al file 
o alla directory per la quale abbiamo richiesto il lock. 

L'interfacciamento con i device dell’Exec 

Come una qualsiasi altra applicazione, un handler può aver li¬ 
bero accesso a tutte le risorse del sistema. E molto comune che 
un handler si avvalga dei device dell'Exec. che, come abbiamo 
già precisato, si pongono tra il dispositivo fisico vero e proprio 
e le applicazioni. Per usare un device Exec, bisogna in primo 
luogo allocare e inizializzare una struttura per effettuare le ri¬ 
chieste di I/O e creare un "reply port" (cioè un message pori 
tramite il quale ottenere le risposte dal device): fatto questo, è 
possibile chiamare la funzione OpenDevice() per ottenere l’ac¬ 
cesso al device desiderato. Quando si termina di usare il devi¬ 
ce, è opportuno rilasciare tale risorsa con la funzione 
CloseDevice(). 

I comandi vengono impartiti al device specificandone il tipo 
desiderato nella struttura di richiesta delle operazioni (e ovvia¬ 
mente inizializzando opportunamente gli altri campi) e chia- 
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mando la funzione DoIO() o la funzione SendlOO, a seconda 
che si desideri un controllo sincrono o asincrono dell’esecuzio¬ 
ne del comando. È comunque opportuno che vi riferiate all’ar¬ 
ticolo relativo ai device apparso sul numero 4 di Transactor e 
alla documentazione ufficiale per tutti i dettagli implementati¬ 
vi. 

Un handler deve preoccuparsi di effettuare le operazioni di ini- 
zializzazione di ogni dispositivo che adopera e, in generale, de¬ 
ve riconoscere e rispondere almeno a un insieme ristretto di 
tipi di richieste, quali l'apertura, la lettura, la scrittura e la chiu¬ 
sura di un file. Inoltre, in certi casi è necessario che lo handler 
riconosca ed esegua anche altri tipi di richieste, come, ad 
esempio. SEEK, EXAMINE_OBJECT, CREATE_DIR ed al¬ 
tre nel caso di un handler per un filing System completo. 

La segnalazione degli errori 

Abbiamo visto che la struttura DosPacket contiene due campi. 
Resi e Res2, che vengono usati per segnalare gli eventuali er¬ 
rori che si siano verificati nel tentativo di soddisfare la richie¬ 
sta specificata nel pacchetto. E necessario che trattiate questi 
campi in maniera conforme alle convenzioni del DOS. 

Quando il campo Resi è posto a 0, viene segnalato un errore e 
Res2 contiene un valore che fornisce ulteriori informazioni sul 
tipo dell’errore che si è verificato. Il valore di Res2 può essere 
ottenuto con la funzione lOErri ) della dos.library. Il file libra- 
ries/dosextens.[hi] contiene i codici di errore definiti a livello 
ufficiale, ma potete comunque definire dei vostri codici parti¬ 
colari per gli specifici errori che possono aver luogo nel vostro 
handler. 

L'implementazione di un handler 

Usualmente, un handler viene impiegato per rendere un device 
Exec disponibile al DOS, ma non deve essere necessaria la 
preesistenza di un device Exec per realizzare un handler; è, in¬ 
fatti, possibile immaginare l’uso di un handler in casi che non 
richiedano affatto l’interazione con un device Exec (si veda, ad 
es„ il programma "ID-handler" del Fish disk #87). 

Quando l’AmigaDOS installa un handler nel sistema, in rispo¬ 
sta al comando Mount, esso crea una struttura Devicelnfo o 
DeviceNode, a seconda che si tratti di un handler per un device 
"filing" o "non-filing", e inserisce la struttura, dopo averne op¬ 
portunamente riempito i campi, nella lista di sistema; dopodi¬ 
ché carica il codice dello handler in memoria e gli crea un 
processo apposito. 

Nel caso in cui si stia installando un device "non-filing", è ne¬ 
cessario che lo handler stesso ponga nel campo dn_Task un 
puntatore al proprio task (più precisamente, alla struttura 
MsgPort associata al task). Così facendo, infatti, TAmigaDOS 
eviterà di creare un nuovo processo handler ogni volta che tro¬ 
va un riferimento al device a cui lo handler è associato, opera¬ 
zione che compierebbe, invece, se il campo dn_Task fosse 
posto a zero. 

Quando TAmigaDOS fa partire il processo dello handler, invia 


allo handler stesso un pacchetto di startup, in cui il campo 
Arg3 contiene un puntatore BCPL alla struttura DeviceNode 
associata allo handler. 

Le prime versioni del sistema operativo imponevano l’uso del 
linguaggio BCPL per la realizzazione degli handler; fortunata¬ 
mente, ora è possibile scrivere gli handler in C o in assembler, 
avendo la precauzione di specificare nella Mountlist -1 come 
GlobVec (il che segnala al DOS che lo handler non è in 
BCPL). 

L'installazione dello handler NEW: 

I moduli BCPL vengono "linkati" run-time attraverso il "global 
vector" che è una tavola comune di indirizzi, mediante la quale 
è possibile accedere alle variabili globali e effettuare una co¬ 
municazione tra moduli. In AmigaDOS i vari componenti ven¬ 
gono tenuti insieme da un global vector e ogni processo 
dispone di un global vector privato per i vari usi interni. 

Affinché un nuovo device DOS possa essere riconosciuto dal 
sistema e possa essere fatto partire lo handler relativo (che sta 
nella directory L: ). è necessario che sia presente nella Moun- 
tlist una sommaria descrizione del nuovo device: in tale descri¬ 
zione, possiamo specificare il nome del file che ospita il codice 
dello handler, le dimensioni dello stack del processo dello han¬ 
dler e la priorità. 

Nel nostro esempio, il file batch do_mount si occupa di far tut¬ 
te le operazioni necessarie per rendere immediatamente dispo¬ 
nibile il nuovo handler NEW:. Si noti che è necessario 
specificare specificare in quale directory sono presenti sia il 
codice dello handler sia la mountlist che contiene la descrizio¬ 
ne di NEW:. 

Dopo aver eseguito il comando 

execute do_raount <directory> 

potrete verificare con il comando assign che NEW: compare 
tra i device disponibili. Un handler per un device "filing" do¬ 
vrebbe anche creare è inserire nella lista di sistema una struttu¬ 
ra che descriva un volume associato al device; solo in tal caso, 
infatti, apparirà l’icona relativa nella finestra del Workbench. 

La prima volta che si dà un comando che accede a NEW;, il 
suo handler viene caricato e fatto partire e dovrebbe apparire 
una finestra in cui vengono stampati dei messaggi relativi al¬ 
l’attività dello handler. 

Che cosa fa NEW: 

L'esempio di handler proposto ha unicamente scopi didattici; 
infatti, riconosce e risponde solo a un limitato numero di pac¬ 
chetti e precisiamente a: OPENRW. OPENOLD, OPENNEW, 
READ, WRITE, CLOSE e DIE. Di conseguenza, le sole fun¬ 
zioni il cui impiego con NEW ha un senso sono: Open(), Clo- 
se(), Read() e Write(). Il modulo test_new.c illustra come 
aprire, usare e chiudere il device NEW:. 


f72~ 


‘b 
























0 


Transactor per AMIGA 


Conclusioni 

Questo articolo ha avuto lo scopo di illustrare la creazione di 
un’interfaccia tra i device Exec e l'AmigaDOS. L’impiego de¬ 
gli handler fornisce una maniera comoda per accedere ai devi¬ 
ce da un’applicazione scritta da un utente senza doversi 
complicare la vita con i reply port e le strutture. Inoltre, l’indi¬ 
pendenza da questi meccanismi laboriosi permette di ottenere 
un’interfacciamento omogeneo tra DOS e device Exec e sem¬ 
plifica drasticamente le operazioni di I/O. 
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Listato 1: new-handler.h 

#ifndef NEW-HANDLER_H 
♦define NEW-HANDLER_H 1 

/*****************************************★********* 

* new-handler.h 

★ 

* header file generale per il nuovo handler 

★ 

* Storia: 

* 12-09-88 creato 

************★**************************************/ 

♦include <functions.h> 

♦include <exec/types.h> 

♦include <exec/memory,h> 

♦include <exec/devices.h> 

♦include <exec/exec.h> 

♦include <exec/io.h> 

♦include <libraries/dos.h> 

♦include <libraries/dosextens.h> 

♦include <libraries/filehandler.h> 

♦include <ctype.h> 

♦include "mydev_def.h" 

♦define DOS_FALSE 0 

♦ define DOS_TRUE -1 

/* comandi di azioni DOS action commands - esistono 
ma non sono definiti in dosextens.h */ 


♦define ACTION_SEEK 1008L 
♦define ACTION_RAWMODE 994L 

extern VOID *AbsExecBase; 

extern VOID btos(), ReturnPktO; 

extern SHORT handle_open(), handle_read(), 

handle_write(), handle_close(); 
extern BYTE *typetostr(); 

/* definizioni di packet DOS addizionali */ 
♦define ACTION_SET_RAW_MODE ACTION_SCREEN_MODE 
♦define ACTION_FIND_INPUT 1005L 
♦defìne ACTION_FIND_OUTPOT 1006L 
♦define ACTION_END 1007L 
♦define ACTION_SEEK 1008L 
♦define MODE_READWRITE 1004L 
♦define MODE_READONLY ACTION_FIND_INPUT 
♦define ACTION_OPENRW MODE_READWRITE 
♦define ACTION_OPENOLD ACTION_FIND_INPUT 
♦define ACTION_OPENNEW ACTION_FIND_OUTPUT 
♦define ACTION_CLOSE ACTION_END 

/* codici d'errore DOS addizionali */ 


♦define ERROR_CANT_CREATE_REPLY 100L 
♦define ERROR_CANT_CREATE_REQDEST 101L 
♦define ERROR_CANT_OPEN_DEVICE 300L 
♦define ERROR_READ_ERROR 301L 
♦define ERROR WRITE ERROR 302L 


/* macro per gestire la conversione di puntatori 
da C a BCPL e viceversa */ 

♦define BPTRtoCptr(Bp) ((BYTE *)((ULONG) (Bp) « 2)) 
♦define CptrtoBPTR(Cp) ((BPTR) ((ULONG) (Cp) » 2)) 

♦endif NEW-HANDLER_H 

Listato 2: imdev_def.h 

/***********************************************★*** 

* mydev_def.h 

* versione C del file mydev_def.i per mydev.device 

* 

* Storia: 

* 88-09-12 creato 

***************************************************/ 

♦ifndef MYDEV_DEF_H 
♦ define MYDEV_DEF_H 1 

♦ifndef EXEC_TYPES_H 

♦include <exec/types.h> 

♦endif EXEC TYPES H 
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#ifndef EXEC_DEVICES_H 
#include <exec/devices.h> 
#endif EXEC_DEVICES_H 

#ìfndef EXEC_IO_H 
♦include <exec/io.h> 
#endif EXEC IO H 


★ 

* Storia: 

* 12-09-88 creato 

~k 

* Compilazione: 

* cc +c +d -b 

* 

**************************************************/ 


♦define MD_NUMUNITS 4 

/* struttura per l'area dati del device mydev */ 
struct MyDev { 


struct 

Device 

md_Device; 

struct 

ExecBase 

*md ExecBase; 

struct 

DosBase 

*md DosBase; 

APTR 


md SegList; 

UBYTE 


md Flags; 

UBYTE 


md pad; 

struct 

Unit 

*md_Units[MD_NUMUNIT S 


) ; 


struct MyDevMsg { 

struct Message 

mdm_Message 

struct 

Device 

*mdm Device 

struct 

Unit 

*mdm Unit; 

struct 

IOStdReq 

*mdm Iob; 


} ; 


struct MyDevUnit { 

UBYTE mdu_UnitNum; 

UBYTE mdu_pad; 

struct MyDevMsg mdu_Msg; 
struct Process *mdu_Process; 

}; 

/* bit di stato e flag per l'unità fermata */ 

♦define MDUB_STOPPED 2 

♦define MDUF_STOPPED (1 « MDUB_STOPPED) 

/* dimensione dello stack e priorità del processo 
che sarà creato */ 

♦define MYPROCSTACKSIZE 0x400 
♦define MYPROCPRI 0 

/* nome del mio device */ 

♦define MYDEVNAME "mydev.device" 

♦endif MYDEV_DEF_H 

Listato 3: routs.c 

/*************************************************** 

* routs.c 

★ 

* Routine di comunicazione dell'handler; 

* comunicazioni con 'mydev.device' 


♦include "new-handler.h" 


/* variabili globali */ 

static struct IOStdReq *req=NULL; /* struttura 

di richiesta al device */ 

static struct MsgPort *reply=NULL; /* Il device 

mette le risposte in questa porta */ 

static BOOL dev_open=FALSE; 
static UBYTE buff[100]; 

/* variabili esterne */ 

extern struct DeviceNode *dn; /* questo nodo 

dell'handler del device */ 

/*************************************************** 

* handle_open() 

* apre il mydev.device per questo handler 
**************************************************/ 

SHORT handle_open(pkt) 

struct DosPacket *pkt; 

{ 

LONG error; 

UBYTE name[20], vol_name[20]; 

USHORT i, len; 

/* nome da aprire */ 
btos(pkt->dp_Arg3,buff) ; 

/* fa una copia e lo mette in maiuscolo */ 
i = 0; 

while ((name[i] = toupper(buff[i])) != ':') i++; 

name[i] = '\0'; 

/* ottiene il nome del nodo del device; è già in 
maiuscolo */ 

btos(dn->dn_Name,vol_name); 
len = strlen(vol_name); 
if (vol_name[len] == ':') 
len—; 

dbprintf("%s %s %s %d\n",buff,name,vol_name,len); 

/* stiamo cercando di aprire il file e non il 
device? */ 

if (strncmp(name,vol_name,len) != 0) 
return(ERROR_DEVICE_NOT_MOUNTED); 
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/* il device è già aperto? */ 
if (dev_open) 

return(ERROR_OBJECT_WRONG_TYPE) ; 

/* crea una reply port */ 
reply = CreatePort("new_handler_reply",0) , 
if (reply==NULL) 

return(ERROR_CANT_CREATE_REPLY); 

/* crea una struttura di richiesta */ 
req = CreateStdIO(reply); 
if (req==NULL) { 

DeletePort(reply); 

reply = NULL; 

return(ERROR CANT CREATE REQUEST); 


/* apre il device */ 

error = OpenDevice(MYDEVNAME,0L,req,0L); 

if (error) { 

DeleteStdIO(req); 

DeletePort(reply); 

req = reply = NULL; 

return(ERROR_CANT_OP EN_DEVICE); 

) 

dev_open = TRUE; 

return (0); 

) /* fine di handle_open */ 

/*************************************************** 

* handle_close() 

* chiude un device aperto - libera tutto ciò che vi 

* è associato 

* ★★★*★*★*★★*★****★*****'****★***********★★****★★*'*★ j 

SHORT handle_close(pkt) 

struct DosPacket *pkt; 

{ 

if (dev_open && req) { 

CloseDevice(req) ; 
dev_open = FALSE; 

} 

if (req) { 

DeleteStdIO(req); 
req = NULL; 

} 

if (reply) { 

DeletePort(reply); 
reply = NULL; 

} 

return(0); 

} /* fine di handle_close */ 

z*************************************************** 

* handle_read() 

* impartisce richieste di lettura a device di 


* sistema 

**************************************************/ 

SHORT handle_read(pkt) 
struct DosPacket *pkt; 

{ 

if (req==NULL) 

return(ERROR_READ_ERROR); 

req->io_Command = CMD_READ; 
req->io_Data = (APTR)pkt->dp_Arg2; 
req->io_Length = pkt->dp_Arg3; 

/* impartisce la richiesta di io */ 

DoIO(req); 

pkt->dp_Resl = req->io_Actual; 
pkt->dp_Res2 = req->io_Error; 

return(0); 

} /* fine di handle_read */ 

/*************************************************** 

* handle_write() 

* impartisce una richiesta di scrittura a device di 

* sistema 

************************************★*************/ 

SHORT handle_write(pkt) 
struct DosPacket *pkt; 

( 

if (req==NULL) 

return(ERROR_WRITE_ERROR) ; 

req->io_Command = CMD_WRITE; 
req->io_Data = (APTR)pkt->dp_Arg2; 
req->io_Length = pkt->dp_Arg3; 

/* impartisce la richiesta di io */ 

DoIO(req); 

pkt->dp_Resl = req->io_Actual; 
pkt->dp_Res2 = req->io_Error; 

return(0); 

) /* fine di handle_write */ 

/* fine del file */ 


Listato 4: dbg.e 

/*************************************************** 

* dbg.C 

★ 

* Codice di debugging per il DOS device handler 

* Storia: 
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* 21-08-88 creato da dosdevice.c di Matt Dillon 

* (disponibile nel Pubblico Dominio) 

* 

* Compilazione: 

* cc -n +c +d +b dbg 
**************************************************/ 

♦include "new-handler.h" 


static struct MsgPort *Dback=NULL; /* reply port 

di debug */ 

static struct MsgPort *Dbport=NULL; /* reply port 

di debug del processo */ 
static USHORT DBDisable=0; /* flag per disabilitare 

la stampa di debug */ 

static struct Message DummyMsg; /* posseduto da 

sotto-processo */ 


extern struct DosLibrary *DOSBase; 


#define DBG_PROCl_PORT_NAME "dbg_reply_port_#l" 
#define DBG_PROC2_PORT_NAME "dbg_reply_port_#2" 

/*****************★★*****************************★** 

* typetostrO 

* restituisce un messaggio del tipo di packet 
**★****************★****★****★********************/ 

BYTE *typetostr(ty) 

LONG ty; 


switch(ty) { 



case 

ACTION_CURRENT_VOLUME: 

return(' 

"CURRENT 

VOL"); 

case 

ACTION_DIE: 

return 

("DIE"); 

case 

ACTION_OPENRW: 

return 

("OPEN-RW"); 

case 

ACTION_OPENOLD: 

return 

("OPEN-OLD") 

case 

ACTION_OPENNEW: 

return 

("OPEN-NEW") 

case 

ACTION_READ: 

return 

("READ"); 

case 

ACTION_WRITE: 

return 

("WRITE") ; 

case 

ACTION_CLOSE: 

return 

("CLOSE"); 

case 

ACTION_SEEK: 

return 

("SEEK"); 

case 

ACTION_EXAMINE_NEXT: 

return(' 

"EXAMINE 

NEXT"); 

case 

ACTION_EXAMINE_OBJECT: 

return("EXAMINE 

OBJ"); 

case 

ACTION_INFO: 

return 

("INFO"); 

case 

ACTION DISK INFO: 




return("DISK INFO") 

case ACTION_PARENT: 

return( 

_DELETE_OBJECT: 

CREATE DIR: 


case ACTION_ 
case ACTION 


PARENTDIR"); 
return("DELETE"); 


case ACTION 
case ACTION 


return(' 
_LOCATE_OBJECT: 
COPY DIR: 


CREATEDIR"); 
return("LOCK"); 
return("DUPLOCK") , 


case ACTION_ 
case ACTION_ 

case ACTION_ 

case ACTION_ 
case ACTION_ 
case ACTION_ 

case ACTION_ 

case ACTION_ 

case ACTION_ 
case ACTION_ 
default : 


FREE_LOCK: 
SET_PROTECT: 

return( 
SET_COMMENT: 

return( 

RENAMEJOBJECT: 
INHIBIT: 

RENAME_DISK: 

return(" 
MORE_CACHE: 

return(" 
WAIT_CHAR: 

return(" 

FLUSH: 

RAWMODE: 

return(" 


return("FREELOCK") ; 

' SETPROTECT"); 

'SETCOMMENT"); 

return("RENAME"); 
return("INHIBIT"); 

'RENAME DISK"); 

'MORE CACHE"); 

’WAIT FOR CHAR"); 
return("FLUSH"); 
return("RAWMODE"); 

-UNKNOWN-") ; 


CODICE DI DEBUGGING. Non si può fare una 
chiamata alla libreria DOS che acceda ad altri 
device dall'interno di un device driver DOS 
perché usa la stessa message port. del driver. Se 
si ha bisogno di una chiamata di questo tipo 
occorre creare la porta e costruirsi il messaggio 
DOS da sé. Non ho fatto questo. Per ottenere 
delle informazioni di debugging ho creato un 
altro processo al quale possono essere mendati i 
messaggi di debugging. 

Vorrete che la priorità del processo di debug sia 
maggiore della priorità del vostro handler DOS. 
Questo per fare in modo che, se il vostro handler 
va in crash, possiate avere una migliore idea del 
punto in cui è morto dai messaggi di debugging 
(ricordate che i due processi sono asincroni 
l'uno rispetto all'altro). 


*/ 


extern VOID debugprocO; 

/************★************************★************* 

* dbinitO 

* inizializza il processo di debugging 

* eseguiamo il processo di debug a una priorità più 

* alta del task originante 
**************************************************/ 

dbinit () 

{ 

struct Task *task = FindTask(NULL ); 

Dback = CreatePort(DBG_PROCl_PORT_NAME,NULL); 
CreateProc("DEV_DB", 

(LONG)task->tc_Node.ln_Pri+l, 

(LONG)CptrtoBPTR(debugproc) , 4096L); 
WaitPort(Dback); /* partenza dell'handshake */ 

GetMsg(Dback); /* rimuove il messaggio dummy */ 


76 


‘b 


















0 Transactor per AMIGA 


dbprintf("Debugger running with %s\n\n" 
task->tc_Node.ln_Name); 

} /* fine di dbinit */ 


/*************************************************** 

* dbuninit() 

* termina il processo di debugging 
**************************************************/ 


dbuninit() 

{ 

struct Message killmsg; 
if (Dbport) { 

killmsg.mn_Length = 0; /* 0 significa fine */ 

PutMsg(Dbport,Skillmsg); 

WaitPort(Dback); /* è terminato */ 

GetMsg(Dback); 

DeletePort (Dback); 


/* 


Poiché il processo di debugging è in 
esecuzione a una priorità più elevata, sono 
sicuro che è garantito che sia completamente 
rimosso prima che questo task riprenda 
nuovamente il controllo. 


Delay(50L); /* assicura che sia terminato */ 


} /* fine di dbuninit */ 

/******★**★***************************************** 

* dbprintf () 

* una routine tipo printf per stampare nella 

* finestra di debug 

**************************************************/ 

dbprintf (a,b,c,d,e,f,g,h,i,j) 

LONG a, b, c, d, e, f, g, i, j ; 

{ 

BYTE buf[256]; 
struct Message *msg; 

if (Dbport && IDBDisable) ( 

sprintf (buf, a, b, c, d, e, f, g, h, i, j) ; 
msg = AllocMem((LONG) 

sizeof(struct Message)tstrlen(buf)+1), 
MEMF_POBLIC | MEMF_CLEAR) ; 
msg->mn_Length = strlen(buf)+1; 
strcpy(msg+l,buf); 

PutMsg(Dbport,msg); 

} 

} /* fine di dbprintf */ 


/*************************************************** 

* debugmain() 

* la routine di debug principale - chiamata dal tag 

* assembler BTW, la DOS library usata da 

* debugmain() è stata aperta dal device driver. 

* Nota: DummyMsg non può essere sullo stack di 

* debugmain() perché debugmain() sparisce con 

* l'handshake finale. 

**************************************************/ 

debugmain() 

{ 

struct Message *msg; 

SHORT len; 

VOID *fh; 

Dbport = CreatePort(DBG_PROC2_PORT_NAME,NULL); 
fh = Open("con:0/0/640/150/Debug Window", 

1006L); 

PutMsg(Dback, SDummyMsg); 
for <;;) ( 

WaitPort(Dbport); 
msg = GetMsg(Dbport); 
len = msg->mn_Length; 
if (len == 0) 
break; 

—len; 

Write(fh, msg+1, (LONG)len); 

FreeMem(msg, 

(LONG)sizeof(struct Message)+len+l); 

} 

Close(fh); 

DeletePort(Dbport); 

PutMsg(Dback,SDummyMsg); /*termina 1'handshake*/ 
} /* fine di debugmain */ 

/*************************************************** 

* debugproc() 

* Il tag assembly per il processo DOS: CNOP causa 

* dei problemi di allineamento con 1'assembler 

* Aztec per qualche ragione. Ho assunto quindi che 

* l'allineamento sia sconosciuto. Poiché la 

* conversione BCPL di base azzera i due bit meno 

* significativi dell'indirizzo, il codice potrebbe 

* iniziare in un qualunque intorno 

* dell'etichetta... Sigh... 


********•****■**■**************■**•*****★★★'**•******■**** 

#asm 

public _debugproc 
public _debugmain 

cseg 

nop 

nop 

nop 

_debugproc: 
nop 
nop 

movem.l D2-D7/A2-A6,-(sp) 


/ 
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jsr _debugmain 

movem.l (sp)+,D2-D7/A2-A6 

rts 

#endasm 

/* fine del file */ 


Listato 5: new-handler.c 

y*************************************************** 

* new-handler.c 

* 

* Codice del device handle AmigaDOS d'esempio 

★ 

* (c) Copyright 1989 Steve Simpson 

* Skarpskyttevagen 20C 

* S-222 42 Lund, SWEDEN 

* 

* Storia: 

* 12-09-88 creato 

* 13-09-88 nessun volume node 

■k 

* compilazione: 

* cc +c +d +b -n new-handler 

* link: 

* In -g -w new-handler routs dbg -lei 
**************************************************/ 

♦include "new-handler.h" 

/* potete ridefinire queste linee */ 

♦define DEBUG 1 
♦define VOLUME 0 

/* variabili esterne */ 
extern struct DosLibrary *DOSBase; 

extern struct ExecBase *SysBase; 


/* variabili globali */ 
struct Process *DevProc; 

struct MsgPort *DevPort; 

struct Message *msg; 

struct Doslnfo *di; 

struct DeviceList *dl; 

struct DeviceNode *dn; 

struct DosPacket *pkt; 


/* questo device 
handler */ 


/* packet ricevuto 
dal DOS */ 


/*************************************************** 

* handler() 

* Questa è la routine principale del modulo - 

* inizializza i puntatori alla libreria, risponde 

* al packet iniziale del DOS e direge le richieste 

* alle routine appropriate. Non abbiamo chiamato 

* questa routine main() in modo da sapere se è 

* stato fatto qualche errore quando arriva il 

* momento del link. 

**************************************************/ 


VOID handler() 

{ 

UBYTE str[100]; 

/* inizializza le variabili globali */ 

SysBase = (struct ExecBase *)AbsExecBase; 

DevProc = (struct Process *)FindTask(0L); 

/* questo task */ 

DOSBase = (struct DosLibrary *) 

OpenLibrary("dos.library",0L); 

/* aspetta il packet iniziale dal DOS */ 

DevPort = &DevProc->pr_MsgPort; 

WaitPort(DevPort); 
msg = GetMsg(DevPort); 

pkt = (struct DosPacket *)msg->mn_Node.ln_Name; 

/* dovremmo impostare DosNode->dn_Task a un 

* valore non-NULL, altrimenti viene creata una 

* nuova istanza del device per ogni 

* riferimento. 

*/ 

if (DOSBase) { 

di = (struct Doslnfo *) 

BPTRtoCptr(((struct RootNode *) 
DOSBase->dl_Root)->rn_Info); 

♦if VOLUME==l 

/* crea un volume node */ 
di = (struct DeviceList *) AllocMem((LONG) 
sizeof(struct DeviceList), 

MEMF_PUBLIC | MEMF_CLEAR); 

♦endif VOLUME 

/* ptr.al device node */ 
dn = (struct DeviceNode *) 

BPTRtoCptr(pkt->dp_Arg3); 

#if VOLUME==l 

/* 'mount' creerà un device node per noi; se 

* stiamo creando un file System device 

* potremmo avere bisogno di includere un 

* volume node così che il WB/DOS ci 

* riconosca come un device. Questo pezzetto 

* di codice è incluso come un esempio e non 

* ha nessuna rilevanza qui, visto che ci 

* stiamo occupando solo di creare un device 

* (eseguite 'assign' dal CLI per capire 

* cosa voglio dire). 

*/ 

dl->dl_Type = DLT_VOLUME; 

dl->dl_Task = DevPort; 

dl->dl_DiskType = ID_DOS_DISK; 
dl->dl_Name = dn->dn_Name; 

dl->dl_Next = di->di_DevInfo; 

di->di_DevInfo = (LONG)CptrtoBPTR(di); 

♦endif VOLUME 

/* imposta il campo dn_Task - questo indica 

* al DOS di non creare un nuovo processo 
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* per ogni riferimento 
*/ 

dn->dn_Task = DevPort; 
pkt->dp_Resl = DOSJTRUE; 
pkt->dp_Res2 = 0; 

ReplyPkt(pkt); 


} 


else { 

pkt->dp_Resl = DOS_FALSE; 

ReplyPkt(pkt); 
return; 

) 

#if DEBUG==1 

/* inizializza il codice di debugging */ 
dbinit ( ) ; 

#endif DEBUG 

/* qui inizia il loop senza fine - aspetta le 

* richieste dalla message port e le esegue 
*/ 

do_control(); 

/* bisogna arrivare qui per rimuovere l'handler; 

* si avrà bisogno di impostare qualche 

* condizione di uscita all'interno del driver 

* per uscire dal loop di controllo e arrivare 

* qui. 

*/ 

remove_handler(); 

#if DEBUG==1 

/* rimuove il sotto-processo di debug */ 
dbuninit(); 

#endif DEBUG 

cleanup(); 

} /* fine di handler */ 


/*************************************★************* 

* do_control() 

* la routine loop (senza fine!). Riceve i 

* susseguenti packet dal DOS e li gestisce. 
***************★★*■****************★***'**★****★**★★/ 

do_control() 

{ 

USHORT quit=FALSE; 

SHORT error; 
struct Task *new_task; 
top : 

quit = FALSE; 
while (!quit) { 

WaitPort(DevPort); 


while (msg = GetMsg(DevPort)) { 
pkt = (struct DosPacket *) 

msg->mn_Node.ln_Name; 

pkt-> dp_Re s1 = DOSJTRUE; 
pkt->dp_Res2 = 0; 

#if DEBUG==1 

dbprintf( 

"Packet; %41d %061x %061x %061x %10s\n", 
pkt->dp_Type,pkt->dp_Argl, pkt->dp_Arg2, 
pkt->dp_Arg3, typetostr(pkt->dp_Type)); 

#endif DEBUG 

/* fa uno switch sul tipo del packet 

* gli argomenti sono messi nella forma: 

* Arg:argl,arg2,arg3, arg4 

* Ris: risi, ris2 
*/ 

switch(pkt->dp_Type) { 

case ACTION_DIE: 
quit = TRUE; 
break; 

/* Arg: FileHandle,Lock,Nome 
Ris: Booleano */ 
case ACTION_OPENRW: 
case ACTION_OPENOLD: 
case ACTION_OPENNEW: 

error = handle_open(pkt); 
break; 

/* Arg: FileHandle,Buffer,Lunghezza 
Ris: Lunghezza effettiva */ 
case ACTIOJJREAD: 

error = handle_read(pkt); 
break; 

/* Arg: FileHandle,Buffer,Lunghezza 
Ris: Lunghezza effettiva */ 
case ACTION_WRITE: 

error = handle_write(pkt); 
break; 

/* Arg: FileHandle 
Ris: Booleano */ 
case ACTION_CLOSE: 

error = handle_close(pkt); 
break; 

/* Arg: Lock,Nome,Modo 
Ris: Lock */ 

case ACTION_LOCATE_OBJECT: 

error = ERROR_BAD_STREAM_NAME; 
break; 

/* Arg: FileHandle,Posizione,Modo 
Ris: Vecchia posizione */ 
case ACTION SEEK: 
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/* Arg: Look,FilelnfoBlock 

Ris: Booleano */ 

} /* while */ 

case ACTION_EXAMINE_NEXT: 

#if DEBUG==1 

new task = (struct Task *)DevProc; 

/* Arg: Lock,FilelnfoBlock 

Ris: Booleano */ 

dbprintf("Can we remove %s? ", 

new task->tc Node.ln Name); 

case ACTION_EXAMINE_OBJECT: 

tendif DEBUG 

/* Arg: Lock,Nome 

Ris: Boolean */ 

Delay(50L); 

Forbid(); 

if (PktsQueued(DevProc)) { 

case ACTION_DELETE_OBJECT: 

Permit(); 

/* Arg: Lock,Nome 

Ris: Boolean */ 

#if DEBUG 

dbprintf("... not yet!\n"); 

case ACTION_CREATE_DIR: 

#endif DEBUG 

case ACTION_COPY_DIR: 

goto top; 

} 

/* Arg: Lock,InfoData 

Ris: Booleano */ 

Permit(); 

return (0) ; 

case ACTION_INFO: 

} /* fine di do control */ 

/* Arg: InfoData 

Ris: Booleano */ 


case ACTION_DISK_INFO: 

/★************************************************** 

* remove handler() 

/* Arg: LockDa,NomeDa,LockA,NomeA 

Ris: Booleano */ 

* rimuove questo handler dalle lista dei nodi 

* device/handler mantenuta dall'AmigaDOS 

case ACTION_RENAME_OBJECT: 

**************************************************/ 

remove handler() 

/* Arg: Lock 

Ris: Boolean */ 

{ 

VOID *dlp; 

case ACTION_FREE_LOCK: 

struct Doslnfo *dsi; 

struct DeviceList *dvl; 

case ACTION_FLUSH: 

dn->dn Task = NULL; 

case ACTION RENAME DISK: 


default : 

/* rimuove questo volume node */ 
dsi = (struct Doslnfo *) 

pkt->dp Resi = DOS FALSE; 

pkt->dp Res2 = ERROR ACTION NOT KNOWN; 

break; 

BPTRtoCptr(((struct RootNode *) 

DOSBase->dl Root)->rn Info); 

dlp = &dsi->di Devlnfo; 

for (dvl = (struct DeviceList *) 

} /* switch */ 

BPTRtoCptr(dsi->di Devlnfo); 

dvl && dvl != di; 

if (error) { 

dvl = (struct DeviceList *) 

pkt->dp Resi = DOS FALSE; 
pkt->dp Res2 = error; 

} 

BPTRtoCptr(dvl->dl_Next)) { 
dlp = &dvl->dl Next; 

) 

if (dvl == di) { 

#if DEBUG==1 

*(BPTR *)dlp = dvl->dl_Next; 

dbprintf( 

"ARG: %061x %061x %061x RIS: %061x %061d\n". 

FreeMem(dvl,(LONG)sizeof(struct DeviceList)); 

} 

pkt->dp Argl,pkt->dp Arg2,pkt->dp Arg3, 
pkt->dp Resl,pkt->dp Res2); 

#endif DEBUG 

#if DEBUG==1 

else { 

dbprintf(" YAH! ! ! - Where's thè volume node\n"); 

ReplyPkt (pkt); 

tendif DEBUG 

} /* while */ 

} /* fine di remove handler */ 
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/**********************************************•***** 

* cleanupO 

* chiude tutto quello che è stato aperto 
*************************★★*************★**********/ 

cleanup ( ) 

{ 

if (DOSBase != NULL) 

CloseLibrary(DOSBase); 

} /* fine di cleanup */ 


/*************************************************** 

* btos() 

* Converte un BSTR in una normale stringa C 
*************★********************************★***/ 

VOID btos(bstr,buf) 

UBYTE *bstr; 

UBYTE *buf ; 


bstr = (UBYTE *)BPTRtoCptr(bstr); 
BCPL_CString(bstr,buf); 

) /* fine di btos */ 


/*************************************************** 

* PktsQueuedO 

* Ci sono dei packet in coda al nostro device? 
**************************************************/ 

PktsQueued(dp) 
struct Process *dp; 

{ 

return ((VOID *)dp->pr_MsgPort.mp_MsgList.lh_Head 
(VOID *)&dp->pr_MsgPort.mp_MsgList.lh_Tail); 

} /* fine di PktsQueued */ 


/*************************************************** 

* ReplyPkt() 

* risponde a un packet DOS; spedisce indietro i 

* packet al DOS 

*******************★******************************/ 
ReplyPkt(pkt) 

register struct DosPacket *pkt; 

{ 

register struct Message *mess; 
register struct MsgPort *replyport; 

/* copia la message reply port */ 
replyport = pkt->dp_Port; 
mess = pkt->dp_Link; 
pkt->dp_Port = DevPort; 
mess->mn_Node.ln_Name = (BYTE *)pkt; 


mess->mn_Node.ln_Succ = NULL; 
mess->mn_Node.ln_Pred = NULL; 

PutMsg(replyport,mess); 

/* fine di ReplyPkt */ 


/*************************************************** 

* BCPL_CString() 

* Assembla una stringa C da una stringa BCPL 

* Una stringa BCPL assomiglia a questo: 

* 

* lung. char char char 

* i -i-t- i -i 


* byteO bytel byte2 byte3 ecc. 
**★***********************************************/ 

BCPL_CString(bcpl, cstr) 

UBYTE *bcpl, /* ptr alla stringa BCPL */ 

*cstr; /* per la stringa restituita */ 

( 

USHORT len; 

len = *(bcpl+0); /* il primo byte fornisce la 

lunghezza della stringa */ 

if (len==0) { 

* (cstr+0) = '\0 '; 
return(0); 

} 

strncpy(cstr,(bcpl+1),len); 

* (cstr+len) = 0; 
return(1); 

} /* fine di BCPL_CString */ 


/* fine del file */ 


Listato 6: test new.c 

/*************************************************** 

* test_new.c 

* 

* Testa le chiamate del nuovo handler 4NEW: device) 

* Storia: 

* 88-11-09 creato 

**************************************************/ 

#include <functions.h> 

♦include <exec/types.h> 

♦include "new-handler.h" 

♦define NEW_NAME "NEW:" 

struct FileHandle *fh; 

UBYTE buff[20]; 
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main() 

( 

LONG len; 

/* apre il device NEW: - la mountlist fornisce 

* l'indicazione su dove si trovi il device 

* handler 
*/ 

fh = Open(NEW_NAME, MODE_NEWFILE) ; 
if (fh==NULL) ( 

printf("Can't open DOS device %s\n",NEW_NAME); 
exit(0) ; 

} 

else 

printf("DOS device %s opened successfully\n", 
NEW_NAME); 

/* cerca di leggere dei dati dal device driver 
*/ 

len = Read(fh, buff, (LONG)sizeof (buff)); 
printf("Read: Actual=%ld\n",len); 

/* ora scrive dei dati al device driver */ 
len = Write(fh, buff, (LONG)sizeof(buff)); 
printf("Write: Actual=%ld\n",len); 

/* chiude il DOS device */ 

Close (fh); 

} /* fine di main */ 

/* fine del file */ 

Listato 7: do mount 

.key directory 
if "<directory> eq "" 

echo "Uso: execute do_mount [assign directory]" 

skip exit 

endif 

assign devs: <directory> 
assign 1: <directory> 
mount "new:" 
binddrivers 

echo "Device NEW: mounted" 

lab exit 


Listato 8: mountlist 

/* mountlist per il nuovo device handler AmigaDOS */ 
NEW: Handler = L:new-handler 

Stacksize = 3000 
Priority = 5 
GlobVec = 1 

# 


(segue da pagina 36) 

Obbedire alle regole! 

Si riscontra un atteggiamento insistente in molti gruppi di pro¬ 
grammazione, i quali sembrano accettare il fatto che, una volta 
che il software non va in crash troppo spesso e che tutte le op¬ 
zioni sono velocemente accessibili, l'interfaccia utente è stata 
rispettata. E la stessa mentalità che parteggia per la produzione 
di cianfrusaglie piuttosto che per un prodotto serio e basilare. 

È ancora tutto così lontano dalla realtà e ci vorrebbe uno studio 
approfondito sotto il punto di vista psicologico, ma questo av¬ 
verrà in seguito. 

La filosofia della Commodore 

La Commodore spiegò la sua filosofia nella prima edizione del 
manuale Intuition: 

"Che cosa è l'interfaccia utente? Questa frase così generica 
comprende tutti gli aspetti che riguardano gli input e gli output 
tra l'utente e la macchina. Include i meccanismi più interni del 
computer e arriva fino al punto di definire una filosofia per 
guidare il rapporto tra l'uomo e la macchina. Intuition è, so¬ 
prattutto. una filosofia trasformata in software." 

"È facile descrivere questa filosofia: l’interazione tra il compu¬ 
ter e l’utente dovrebbe essere semplice, divertente e coerente, 
detto in una parola, intuitiva. Intuition fornisce un insieme di 
strumenti e di ambienti che possono essere utilizzati per andare 
incontro a questa filosofia." 

"Vi si incoraggia a sfruttare le varie caratteristiche di Intuition. 
Facendo questo raggiungerete due scopi: passerete meno tem¬ 
po ad implementare per conto vostro i meccanismi di interazio¬ 
ne utente... e l'utente del vostro prodotto si troverà a lavorare 
in un ambiente che non cambia radicalmente da un’applicazio¬ 
ne all'altra." 

"Non importa quanto il vostro programma sia semplice o fanta¬ 
sioso, si adatterà alle regole base delFambiente Intuition... L’u¬ 
tente apprenderà gli elementi base di Intuition ed imparerà ad 
avere fiducia nel fatto che i blocchi centrali resteranno tali. 
Questa coerenza assicura che un programma ben progettato 
verrà compreso dall'utente principiante come pure da quello 
sofisticato." 

"Questa è l'essenza e la bellezza della filosofia di Intuition” 

Se solo le software house rispettassero questo e mettessero da 
parte la loro presunzione e la loro arroganza... Il software è per 
l’utente, non per Lego della società autrice! 
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PER TE FAVOLOSI 


PREMI 

Ecco una nuova straordinaria iniziativa del Gruppo 
Editoriale Jackson: è lo speciale concorso riservato a te 
e dedicato al tuo fantastico Amiga. 

Partecipare è facile: basta acquistare uno dei nove 
libri Jackson per i computer Amiga, compilare la 
speciale cartolina che trovi dal tuo rivenditore 
di fiducia e spedirla. 

E' facile anche vincere e i premi in palio sono 
fantastici: un personal computer Commodore 
Amiga 2000, una stampante a colori Commodore 
MPS 1500C e 8 set di programmi software della 
serie "Software Commodore by CTO". 
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Dalla collaborazione con la rivista Compute!’s Amiga Resource, è nata l'Amiga 
che aspettavate! Chiara, aggiornatissima, più ricca, Amiga Magazine è la rivista 
ideale per il programmatore e adatta anche per i meno esperti. La nuovissima 
AMIGA MAGAZINE è già in edicola. Non perdetela !! 
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